Re: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II

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

Hi Pedro,

The answers to the specific questions are given below. I will also
update my proposal later.

> 1) How are you planning to reconcile the cargo build system with EDK2's build system?

Well, a lot of work for this was already done in edkii-rust branch of
edk2-staging. So most of the .dsc and other files needed for Rust are
already present, they will just need to be updated/verified.

The main change I have in mind right now is using the build-std cargo
feature (https://doc.rust-lang.org/cargo/reference/unstable.html#build-std)
instead of cargo-xbuild. It basically can do what cargo-xbuild did but
is baked into cargo instead of an external tool.

I am planning on supporting the following combinations of building:
1. C source + Rust source mixed in INF (Library or Module)
2. Pure Rust Module only
3. Pure Rust Module + Pure Rust Library with Cargo Dependency
4. Pure Rust Module + C Library with EDKII Dependency
5. C Module + Pure Rust Library with EDKII Dependency
6. Pure Rust Module + Pure Rust Library with EDKII Dependency

> 2) If you go ahead with cargo, will the new Rust code require a lot of tiny crates? I'm personally not very enthusiastic about having lots of dependencies all over the place,

Shouldn't the decision of how many crates to use be left up to the
driver creators? I personally also like minimizing external
dependencies, especially in a project such as this, even if I have to
reimplement some things myself. But using cargo has a lot of benefits,
especially in the 2, 3, 4, and 6 building combinations.

Also, building with EDKII tools will also be a first-class citizen, so
cargo won't be the only option.

> 3) How much of std are you going to implement? Note that traditionally, EDK2, like a lot of this firmware/kernel/bootloader code, doesn't actually implement much of the standard library (and that's the reasoning behind edk2-libc).

First and foremost, I will implement a global allocator using the
`AllocatePool()` boot service. This will allow me to compile `alloc`
crate which is the crate that actually contains all the types such as
`std::collections`, `Vector`, `Box`, `Rc`, `String`, etc. All of these
types should now magically work theoretically, however since UEFI is a
tier 3 target in Rust, there is a moderate chance that manual
intervention will be needed here. Thus a lot of testing will be needed
here.

Once that is done, I will work to add `std::ffi::OsString` support.
This is important since the default strings in Rust use UTF-8 while
the default string type in UEFI is 16bit Unicode.

Finally, I will work on writing a basic test framework since the
default Rust testing framework cannot be used in uefi environment.
This will be done using `custom-test-frameworks feature
(https://doc.rust-lang.org/unstable-book/language-features/custom-test-frameworks.html).

I am open to suggestions if you believe that any other parts of std
need to be implemented. However, the above portion is what I had in
mind.

> 4) Do you have any idea of what DXE driver you're going to implement? Do you have any experience writing drivers?

No, I do not yet have any experience with writing UEFI drivers. I have
found some resources online about writing drivers with edk2 but this
will be my first time actually doing it. That is why I have mentioned
in the proposal that I will be trying to write a small driver in C
first during the community bonding period.

As for the specific driver, while I don't have any specific driver in
mind, and thus will need help from mentors to decide, I do have an
idea about what the driver should contain. They are as follows:
1. It should be complex enough to contain the common parts of edk2
that are actually used in production drivers. So drivers like
HelloWorld are out.
2. It should be able to serve as an example for writing DXE drivers in Rust.
3. It should also serve as a test of sorts, but I think that's a given
by the virtue of previous points.

> 5) Any plans for generation of C <-> Rust bindings? Does https://github.com/rust-lang/rust-bindgen work out of the box?

I'm not quite sure about this yet. Bingen is great but there is no
need to use it if there are only a few C methods/structures that I
need to use. On the other hand, it is great when there is a lot of C
code that needs to be used from Rust. It might be helpful in 1 and 5
build combinations, but I think this needs additional discussion.

It can also be useful for `ShellPkg`, `NetworkPkg`, etc. However, I
think I will get a better understanding by actually writing a driver.


Feel free to give suggestions and ask more questions. I would be happy
to answer them.

Ayush Singh.