[edk2-devel] Proposal to move Rust std work to a Repository under Tianocore
Leonardo Garcia
leonardo.garcia at linaro.org
Mon Aug 1 21:16:10 UTC 2022
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 at edk2.groups.io <devel at edk2.groups.io> *On Behalf Of
>> *Ayush Singh
>> *Sent:* Tuesday, August 2, 2022 1:50 AM
>> *To:* Pedro Falcato <pedro.falcato at gmail.com>; edk2-devel-groups-io
>> <devel at edk2.groups.io>
>> *Cc:* Kinney, Michael D <michael.d.kinney at intel.com>; Michael Kubacki
>> <mikuback at linux.microsoft.com>; Yao, Jiewen <jiewen.yao at intel.com>;
>> Gaibusab, Jabeena B <jabeena.b.gaibusab at 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 at 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
>>
>>
>>
>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92032): https://edk2.groups.io/g/devel/message/92032
Mute This Topic: https://groups.io/mt/92752888/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20220801/eb749289/attachment-0001.htm>
More information about the edk2-devel-archive
mailing list