Re: [edk2-devel] Proposal to move Rust std work to a Repository under Tianocore

["Ayush Singh" <ayushdevel1325@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9658 bytes --]

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 <devel@edk2.groups.io> *On Behalf Of 
> *Ayush Singh
> *Sent:* Tuesday, August 2, 2022 1:50 AM
> *To:* Pedro Falcato <pedro.falcato@gmail.com>; edk2-devel-groups-io 
> <devel@edk2.groups.io>
> *Cc:* Kinney, Michael D <michael.d.kinney@intel.com>; Michael Kubacki 
> <mikuback@linux.microsoft.com>; Yao, Jiewen <jiewen.yao@intel.com>; 
> Gaibusab, Jabeena B <jabeena.b.gaibusab@intel.com>
> *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, <ayushdevel1325@gmail.com>
>     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
>
>
>
>
>
> 

[-- Attachment #2: Type: text/html, Size: 17403 bytes --]