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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88525): https://edk2.groups.io/g/devel/message/88525 Mute This Topic: https://groups.io/mt/90247496/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
