From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by mx.groups.io with SMTP id smtpd.web10.5607.1649332923891868211 for ; Thu, 07 Apr 2022 05:02:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=HTkyPx/6; spf=pass (domain: gmail.com, ip: 209.85.166.179, mailfrom: ayushdevel1325@gmail.com) Received: by mail-il1-f179.google.com with SMTP id k15so4076762ils.0 for ; Thu, 07 Apr 2022 05:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lx3bgJiO5K05+lcVyPKX1SWBhxUSbSsKv8jOgVmmK4=; b=HTkyPx/6w3Bsoi7HC2c2D2+X9kwhsC7O0QhNLY81DJY4KpmdLc/ImfNFHQl4KdJssX sdxynDo0xkQcVOY0EUXGBoDFzvOqiEprP+Z2FYkGWjgd99UbiqiVYnY/RZsvuWJZds2z TRCFyh17SEvkR5AkUc3cFQdc5vWMVtK/rPq8h01EwXlaPYmKYKl/8UQxRzE8rXYNBTRF EreUMl3kclZvy9A6GMPEWVfIysqcx+bTwkEn9rf1ReOvL8oDCCsCQEqzf53lU9Op+UiM Oo9abn/KgaANkz7T8Z9s0D6KBUUYsIohB/DxRtqzzJjlf9V2ZjM967QEz8d33JaHhNGf /+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5lx3bgJiO5K05+lcVyPKX1SWBhxUSbSsKv8jOgVmmK4=; b=Og9vrLOJCR3E5oTkxztnjk8tdeGbKgQp9EPiiJAWPjkFu0OEwZLKpcONobaMUErLYf bcUHu0kFCoGtXfepqU+5M4zd6GLm60Kfmu8l04t9gNgi3TJNVVHD1HnnGl9qdgsB6UIO ng35xoJsSQBz3QTPt99KTASw8rrG9Ry5RNy/cfrlzPCX0OEYUFdlcuYu+ZCjfP4TzH2O 2Jtzm8ccyhKtCq3Hl1YARxjZlb5ybjtUhnqF7vOGAJcZeBeQ5DWj4KuJ1x1fSE1ZoqZQ OefT+4V9DyEGQQNAGw7UN7/q1869Xtwm9A93pyb38fZk5RS6moRnIBdirUZzEe4iNLye n4qQ== X-Gm-Message-State: AOAM532muxahGa6Er2QKxozd13UO5eL0XL2RE+7Tut+SdOXNDJRIBDR5 9kzk+2hwGgywtAJ/di8YJKpZND/Mng7mt5+zgUo= X-Google-Smtp-Source: ABdhPJyqiZQXifkMy6emTHn2owT4jEqtCjnNIz3oR2Z8QffQerB3h5GgZEaR91dmgcUQW8cNtp7xPY+42XuL/R/O2LQ= X-Received: by 2002:a05:6e02:1526:b0:2c9:c4cd:c9d with SMTP id i6-20020a056e02152600b002c9c4cd0c9dmr6468696ilu.65.1649332923091; Thu, 07 Apr 2022 05:02:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ayush Singh" Date: Thu, 7 Apr 2022 17:31:52 +0530 Message-ID: Subject: Re: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II To: Pedro Falcato Cc: edk2-devel-groups-io , Bret Barkelew , Nate DeSimone , =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: text/plain; charset="UTF-8" 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.