On 2022/08/01 15:55, Ayush Singh wrote: > > 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. > This is currently under development, I suppose: https://edk2.groups.io/g/devel/message/91941 Cheers, Leo >   - [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 >> >> >> >> >> >