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 ||||`panic-abort-tests` option is broken (the tests do output to stdio correctly). 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 > > *From:* devel@edk2.groups.io *On Behalf Of > *Ayush Singh > *Sent:* Tuesday, August 2, 2022 1:50 AM > *To:* Pedro Falcato ; edk2-devel-groups-io > > *Cc:* Kinney, Michael D ; Michael Kubacki > ; Yao, Jiewen ; > Gaibusab, Jabeena B > *Subject:* Re: [edk2-devel] Proposal to move Rust std work to a > Repository under Tianocore > > 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. > > Thanks, > > Pedro > > On Mon, 1 Aug 2022, 18:02 Ayush Singh, > wrote: > > 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 > > > > > >