Hi Yao Jiewen. The currently implemented portions in the `std::sys` module would have to be
the following:
- [x] alloc
- [x] GlobalAlloc: Currently uses hardcoded `EFI_MEMORY_TYPE::EfiLoaderData`. Can be
changed.
- [x] args
- [x] cmath: Provided by `compiler_builtins` for UEFI.
- [x] env: Just contains some constants
- [ ] fs
- [ ] File: Works for file on any volume as long as path can
be converted to DEVICE_PATH_PROTOCOL
- [x] open
- [x] file_attr
- [x] *fsync: Uses `EFI_FILE_PROTOCOL.Flush()` internally
- [x] *datasync: Uses fsync internally
- [x] truncate
- [x] read
- [x] *read_vectored: Using rust default implementation.
- [x] is_read_vectored
- [x] write
- [x] *write_vectored: Using rust default implementation.
- [x] is_write_vectored
- [x] flush: Don't really maintain any buffer in Rust side.
- [x] seek
- [ ] duplicate
- [x] set_permissions
- [x] FileAttr
- [x] ReadDir
- [x] DirEntry
- [x] OpenOptions
- [x] FilePermissions
- [x] FileType
- [x] *is_symlink: Just returns false since I don't think
UEFI supports symlinks.
- [x] DirBuilder
- [x] readdir
- [x] unlink
- [x] rename
- [x] set_perm
- [x] rmdir
- [x] remove_dir_all
- [x] try_exists
- [ ] readlink
- [ ] symlink
- [ ] link
- [x] stat
- [x] lstat
- [ ] canonicalize
- [ ] copy
- [x] *io: Using the default implementation at
`unsupported/io.rs`. It works fine.
- [x] *locks: Using the default implementation at
`unsupported/locks.rs`. It should work for any target having
just a single-thread.
- [ ] *net: Only implmented TCPv4 right now.
- [ ] TcpStream
- [x] connect
- [ ] connect_timeout
- [ ] set_read_timeout
- [ ] set_write_timeout
- [ ] read_timeout
- [ ] write_timeout
- [ ] peek
- [x] read
- [x] read_vectored
- [x] is_read_vectored
- [x] write
- [x] write_vectored
- [x] is_write_vectored
- [x] peer_addr
- [x] socket_addr
- [ ] *shutdown: Only implemented complete shutdown right
now.
- [ ] duplicate
- [ ] linger
- [ ] set_nodelay
- [x] nodelay
- [ ] set_ttl
- [x] ttl
- [ ] take_error
- [ ] set_nonblocking
- [ ] TcpListener
- [x] bind
- [ ] socket_addr
- [x] accept
- [ ] duplicate
- [ ] set_ttl
- [x] ttl
- [ ] set_only_v6
- [ ] only_v6
- [ ] take_error
- [ ] set_nonblocking
- [ ] UdpSocket
- [ ] os
- [x] errno
- [x] error_string
- [x] getcwd: Returns the Text representation of
`EFI_DEVICE_PATH_PROTOCOL`. This can be directly converted to
`EFI_DEVICE_PATH_PROTOCOL` using the
`EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL`.
- [ ] chdir
- [ ] SplitPaths
- [ ] split_paths
- [ ] JoinPaths
- [ ] join_paths
- [x] current_exe: Returns the Text representation of
`EFI_DEVICE_PATH_PROTOCOL`. This can be directly converted to
`EFI_DEVICE_PATH_PROTOCOL` using the
`EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL`.
- [ ] Env
- [ ] env
- [x] *getenv: Currently using a static Guid. Maybe should use
the Guid used by UefiShell for Environment Variables.
- [x] setenv
- [x] unsetenv
- [ ] temp_dir
- [ ] home_dir
- [x] exit
- [ ] getpid
- [x] os_str: Basically just UTF-8 strings. This is because
os_str is supposed to be the superset of both the OS specific
string(UCS-2) and Rust strings (UTF-8).
- [x] Buf
- [x] Slice
- [x] path
- [ ] pipe
- [ ] *AnonPipe: Implemented using Runtime Variables.
- [x] read
- [x] read_vectored: Using default implementation
- [x] is_read_vectored
- [x] write
- [x] write_vectored: Using default implementation
- [x] is_write_vectored
- [ ] diverge
- [x] *read2: It is blocking and synchronous right now
- [ ] process
- [ ] Command
- [x] new
- [x] arg
- [x] env_mut
- [ ] cwd
- [ ] *stdin: Only null working yet.
- [x] *stdout: Using my primitive AnonPipe
- [x] *stderr: Using my primitive AnonPipe
- [x] get_program
- [x] get_args
- [x] get_envs
- [x] get_current_dir
- [x] *spawn: Currently calling
`EFI_BOOT_SERVICES.StartImage()` here since the pipes don't
really work asynchronously right now.
- [x] StdioPipes
- [x] Stdio
- [x] ExitStatus
- [x] exit_ok
- [x] code
- [x] ExitStatusError
- [x] code
- [x] ExitCode
- [x] as_i32
- [ ] Process
- [ ] id
- [ ] kill
- [x] wait
- [ ] try_wait
- [ ] CommandArgs
- [x] stdio
- [x] *STDIN_BUF_SIZE: Currently using the same value as
Windows
- [x] Stdin
- [x] *read: Buffered reading not implemented yet.
- [x] Stdout
- [x] Stderr
- [ ] thread
- [x] sleep
- [ ] thread_local_key: Using `unsupported/thread_local_key.rs`
- [x] time
- [x] Instant: Implemented same as `SystemTime`
- [x] SystemTime: Implemented using `GetTime()`
All the tests for Global Allocator pass as well, so all the
alloc types should work without any problem. The most fragile
portions are probably `process` and `net` module. They were
basically implemented for running the tests and so, only the
portions that are required were implemented. Finally, the whole
`libtest` mostly works, although the stdio capturing with
As for the up-streaming, the requirements aren't all that
strict (since its a Tier-3 target). The current implementation
should technically be enough to at least open a PR. I would like
to fix a few things before opening the PR (and add the
documentation of what Protocols the different portions of std
use). I have been in touch with the UEFI Rust maintainer @David
Rheinsberg, so it should be straightforward to get the review
process going.
The PR getting merged isn't really a GSoC target (although it
would certainly be great). However, getting the project to a
state, where the major hurdles for merging and usability are
overcome is certainly a goal. Also, I am planning on completing
the merge (and possibly helping future UEFI contributions
upstream), even after GSoC duration is over.
Ayush Singh
On 8/1/22 23:37, Yao, Jiewen wrote:
Hi Ayush
Thanks for the great work.
Would you please help me understand that
how far we are between current [1] and final upstream to
Rust?
Is upstreaming a goal of GSoC project?
Thank you
Yao Jiewen
Hi Pedro. To clarify the original email. The proposal is
not to create a new repository to start Rust std work.
Rather, it is to move all the per-existing work that I have
done for implementing std since the beginning of GSoC. This
work can be found in my personal fork [1]. A significant
portion of std is already in a working state for DXE UEFI
and is at a point that a PR can be opened in a few weeks
upstream to get it merged. A fork under Tianocore would
allow more people, form both Rust and Tianocore side to
experiment/improve the std, with the final goal of getting
it all merged in upstream Rust.
Yours Sincerely
Ayush Singh
[1]: https://github.com/Ayush1325/rust/tree/uefi-std-rebase
On 8/1/22 22:56, Pedro Falcato wrote:
Hi,
May I suggest you just port the
bare rust language (no crates, no std) to EDK2? It
seems far more plausible to expect people to use a cut
down version with some bindings to the rest of the
project instead of hoping people just use the whole of
rust, a lot of which isnt proven (or even used AFAIK)
in bare metal projects. Porting just the bare minimum
is way more realistic in my opinion.
Hello
everyone. In the previous email thread [1], I
discussed the
proposal to move Rust std work to edk2-staging and
mentioned its
potential problems. After some discussion with
mentors, we arrived at
the conclusion to have a rustlang [2] fork under the
Tianocore
organization, and move all the std related work there.
We can then open
a PR upstream from there, while allowing PRs in this
repository. This
should help provide an easier and streamlined way for
people to
experiment and work on this project while it is in the
process of being
merged upstream.
For a status update about tests:
- passed: 12797
- failed: 40
- ignored: 375
Yours Sincerely,
Ayush Singh
[1]: https://edk2.groups.io/g/devel/message/91989
[2]: https://github.com/rust-lang/rust