Proposal to move Rust std work to a Repository under Tianocore

Proposal to move Rust std work to a Repository under Tianocore

[Ayush Singh]

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

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

[Pedro Falcato]

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

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: 2007 bytes --]

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

[Ayush Singh]

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

Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support for 
no_std Rust has been present upstream for a few years. However, as you 
might be able to guess, bare Rust without any allocation and use of 
external crates simply did not provide enough benefits over C to migrate 
older projects to it. Additionally, without std, it's difficult to do 
enough significant testing to generate enough confidence in a new 
language like this.

Also to clarify, using Rust std in an application does not mean the 
whole std will be bundled with the application. Only the parts of std 
that are actually used by the application will be bundled in the final 
binary.

You can find more information about what is already present in upstream 
Rust for UEFI here: 
https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html

There is also some talks about promoting UEFI target to Tier-2, and 
having an std implementation will certainly help with that.


Yours Sincerely.

Ayush Singh


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: 4549 bytes --]

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

[Pedro Falcato]

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

Right. I had no idea that you were going to go for std support in your
project. This makes me like your project much less. I thought you were
going to go the way of linux, where they do not use std but rather custom
stuff that fits well with the rest of the kernel. I very much do not think
that a whole standard library (especially a full-fledged one like Rust's)
is useful, or fits well, or is even usable in this context; this is why no
one that is working on firmware or a kernel uses your userspace's libc, C++
standard library or rust's std. I can see how std can be useful when trying
to run standalone EFI apps, but the security critical code is the rest of
EFI, which needs to fit the EDK2 system and sometimes run in awkward
contexts like runtime services, SMM, etc.

Is there no chance to upstream build integration and some basic wrappers
around existing code?

On Mon, Aug 1, 2022 at 6:39 PM Ayush Singh <ayushdevel1325@gmail.com> wrote:

> Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support for
> no_std Rust has been present upstream for a few years. However, as you
> might be able to guess, bare Rust without any allocation and use of
> external crates simply did not provide enough benefits over C to migrate
> older projects to it. Additionally, without std, it's difficult to do
> enough significant testing to generate enough confidence in a new language
> like this.
>
> Also to clarify, using Rust std in an application does not mean the whole
> std will be bundled with the application. Only the parts of std that are
> actually used by the application will be bundled in the final binary.
>
> You can find more information about what is already present in upstream
> Rust for UEFI here:
> https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html
>
> There is also some talks about promoting UEFI target to Tier-2, and having
> an std implementation will certainly help with that.
>
>
> Yours Sincerely.
>
> Ayush Singh
>
>
> 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
>>
>>
>>
>> 
>>
>>
>>

-- 
Pedro Falcato

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

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

[Michael D Kinney]

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

Hi Pedro,

These ideas have been discussed.  These are all valuable and would be required
to use Rust in PEI, DXE, and SMM environments as part of system firmware images.

However, there is also a desire to use other rust crates that depend on std.
Those are not usable without std support.  So starting with a UEFI env with
full std that passes all rust unit tests and can be unstreamed to the rust
project provides a solid foundation to expand into the PEI, DXE, and SMM
environments and work on integration into the EDK II build system.

I consider UEFI std support to be a prerequisite for your ideas.

Thanks,

Mike

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Monday, August 1, 2022 12:06 PM
To: Ayush Singh <ayushdevel1325@gmail.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; 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

Right. I had no idea that you were going to go for std support in your project. This makes me like your project much less. I thought you were going to go the way of linux, where they do not use std but rather custom stuff that fits well with the rest of the kernel. I very much do not think that a whole standard library (especially a full-fledged one like Rust's) is useful, or fits well, or is even usable in this context; this is why no one that is working on firmware or a kernel uses your userspace's libc, C++ standard library or rust's std. I can see how std can be useful when trying to run standalone EFI apps, but the security critical code is the rest of EFI, which needs to fit the EDK2 system and sometimes run in awkward contexts like runtime services, SMM, etc.

Is there no chance to upstream build integration and some basic wrappers around existing code?

On Mon, Aug 1, 2022 at 6:39 PM Ayush Singh <ayushdevel1325@gmail.com<mailto:ayushdevel1325@gmail.com>> wrote:

Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support for no_std Rust has been present upstream for a few years. However, as you might be able to guess, bare Rust without any allocation and use of external crates simply did not provide enough benefits over C to migrate older projects to it. Additionally, without std, it's difficult to do enough significant testing to generate enough confidence in a new language like this.

Also to clarify, using Rust std in an application does not mean the whole std will be bundled with the application. Only the parts of std that are actually used by the application will be bundled in the final binary.

You can find more information about what is already present in upstream Rust for UEFI here: https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html

There is also some talks about promoting UEFI target to Tier-2, and having an std implementation will certainly help with that.



Yours Sincerely.

Ayush Singh


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<mailto: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







--
Pedro Falcato

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

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

[Ayush Singh]

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

Well, testing without std is quite difficult (`uefi-rs` does have some 
support for it). For the bare targets of Linux, they simply use the std 
linux targets for testing and that works fine. Not so much for a bare 
target without an std counterpart.

Also, Rust for Linux project is a bit of a special case. There is only 1 
main Linux Kernel and that's all. This essentially means u can create 
all the Rust tooling in the Kernel, and then all the crates for the 
Kernel development can depend on those modules/drivers in the Kernel. 
Essentially, the Kernel here acts as the standard library itself.

UEFI is a specification that can have many implementations. There is no 
single source of truth for all UEFI crates/modules to depend on. This 
means, any crate/application you want to create for UEFI (not just 
edk2), will have to start from scratch without anything to base on.

It might be possible to extract the allocator and other stuff from the 
std so that they can be used without std, but that's not really the goal 
right now.


Ayush Singh


On 8/2/22 00:36, Pedro Falcato wrote:
> Right. I had no idea that you were going to go for std support in your 
> project. This makes me like your project much less. I thought you were 
> going to go the way of linux, where they do not use std but rather 
> custom stuff that fits well with the rest of the kernel. I very much 
> do not think that a whole standard library (especially a full-fledged 
> one like Rust's) is useful, or fits well, or is even usable in this 
> context; this is why no one that is working on firmware or a kernel 
> uses your userspace's libc, C++ standard library or rust's std. I can 
> see how std can be useful when trying to run standalone EFI apps, but 
> the security critical code is the rest of EFI, which needs to fit the 
> EDK2 system and sometimes run in awkward contexts like runtime 
> services, SMM, etc.
>
> Is there no chance to upstream build integration and some basic 
> wrappers around existing code?
>
> On Mon, Aug 1, 2022 at 6:39 PM Ayush Singh <ayushdevel1325@gmail.com> 
> wrote:
>
>     Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support
>     for no_std Rust has been present upstream for a few years.
>     However, as you might be able to guess, bare Rust without any
>     allocation and use of external crates simply did not provide
>     enough benefits over C to migrate older projects to it.
>     Additionally, without std, it's difficult to do enough significant
>     testing to generate enough confidence in a new language like this.
>
>     Also to clarify, using Rust std in an application does not mean
>     the whole std will be bundled with the application. Only the parts
>     of std that are actually used by the application will be bundled
>     in the final binary.
>
>     You can find more information about what is already present in
>     upstream Rust for UEFI here:
>     https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html
>
>     There is also some talks about promoting UEFI target to Tier-2,
>     and having an std implementation will certainly help with that.
>
>
>     Yours Sincerely.
>
>     Ayush Singh
>
>
>     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
>>
>>
>>
>>         
>>
>>
>
>
> -- 
> Pedro Falcato

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

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

[Ayush Singh]

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

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: 4215 bytes --]

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

[Yao, Jiewen]

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

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<mailto: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: 6585 bytes --]

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

[Ayush Singh]

[-- 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 --]

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

[Leonardo Garcia]

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

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 <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: 19450 bytes --]

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

[Michael D Kinney]

Hi Ayush,

I have created a fork in tianocore

	https://github.com/tianocore/rust

I have added you and the EDK II Maintainers as collaborators on this repo.

Please let me know if any permission changes need to be made for you
to migrate your work into this repository.

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
> Sent: Monday, August 1, 2022 10:02 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; mikuback@linux.microsoft.com; Yao, Jiewen <jiewen.yao@intel.com>; Gaibusab,
> Jabeena B <jabeena.b.gaibusab@intel.com>
> Subject: [edk2-devel] Proposal to move Rust std work to a Repository under Tianocore
> 
> 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
> 
> 
> 
> 
> 

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

[Ayush Singh]

Hi Mike. What should be the naming scheme of the branch/s? I think you 
already had some in mind to handle the development workflow.

Ayush Singh


On 8/1/22 23:43, Michael D Kinney wrote:
> Hi Ayush,
>
> I have created a fork in tianocore
>
> 	https://github.com/tianocore/rust
>
> I have added you and the EDK II Maintainers as collaborators on this repo.
>
> Please let me know if any permission changes need to be made for you
> to migrate your work into this repository.
>
> Thanks,
>
> Mike
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
>> Sent: Monday, August 1, 2022 10:02 AM
>> To: devel@edk2.groups.io
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; mikuback@linux.microsoft.com; Yao, Jiewen <jiewen.yao@intel.com>; Gaibusab,
>> Jabeena B <jabeena.b.gaibusab@intel.com>
>> Subject: [edk2-devel] Proposal to move Rust std work to a Repository under Tianocore
>>
>> 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
>>
>>
>>
>>
>>
>
>
> 
>
>

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

[Michael D Kinney]

Hi Ayush,

Since this is a fork of the rust project, I would
recommend following the branch naming convention used
by other PRs in the rust project.

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
> Sent: Monday, August 1, 2022 12:01 PM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: 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 Mike. What should be the naming scheme of the branch/s? I think you
> already had some in mind to handle the development workflow.
> 
> Ayush Singh
> 
> 
> On 8/1/22 23:43, Michael D Kinney wrote:
> > Hi Ayush,
> >
> > I have created a fork in tianocore
> >
> > 	https://github.com/tianocore/rust
> >
> > I have added you and the EDK II Maintainers as collaborators on this repo.
> >
> > Please let me know if any permission changes need to be made for you
> > to migrate your work into this repository.
> >
> > Thanks,
> >
> > Mike
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
> >> Sent: Monday, August 1, 2022 10:02 AM
> >> To: devel@edk2.groups.io
> >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; mikuback@linux.microsoft.com; Yao, Jiewen <jiewen.yao@intel.com>;
> Gaibusab,
> >> Jabeena B <jabeena.b.gaibusab@intel.com>
> >> Subject: [edk2-devel] Proposal to move Rust std work to a Repository under Tianocore
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> 
> 
> 
>