Le sam. 22 mars 2025, 03:20, Andrew Hamilton <adham...@gmail.com> a écrit :
> Hello, > > Personally, I really like this idea. > > I'm not yet a Rust programmer but I am happy to learn... and perhaps > there are others like me that would take this as an opportunity to > learn while doing something like porting a Grub module from C to Rust > if we had that framework in place. > This is more complicated than it seems. Mainly for 2 reasons: 1. For i386-pc core with part_msdos+biosdisk+<simple filesystem> has to fit into 31K (compressed) of an old MBR gap. Simple programs in Rust even stripped clock in 10-50K. Idk if this can be reduced somehow. 2. ia64 has no rust AFAICT. I'm unsure what to do with it. Whether to drop ia64 is an interesting question that would need to be discussed separately. 3. Sparc64 allocates only about 1M of heap. Idk if it's enough for Rust. Sparc64 has more RAM than this even in the most restricted scenario but we need to figure out MMU if we want more heap Neither however prevents from creating new code in rust or to port some modules to C. New filesystem sounds like a perfect candidate for rust. Rewriting a part map that isn't msdos (due to i386-pc) or gpt (due to ia64) is also a possibility > > It seems like a nice way to hopefully eliminate or reduce certain > kinds of bugs as well. > > It may also be a nice opportunity to make some common processes with > the Rust community like perhaps using rustfmt as the coding standard > to reduce burden on developers and maintainers to deal with formatting > and focus on functionality. > Do you know how to bring them in? Already at current stage their expertise is valuable in order to get an idiomatic Rust. > > I like that you have a small demo module as well in what you did, it > shows a nice starting point for people wanting to take on a module if > this gains traction like I hope it will. > > Thanks! > Andrew > > On Fri, Mar 21, 2025 at 3:53 PM Vladimir 'phcoder' Serbinenko > <phco...@gmail.com> wrote: > > > > Hello, I was playing with adding Rust embedded in GRUB. I’ve pushed > results to 2 repos: > > Module goes to https://github.com/phcoder/grub-rust-hello/tree/master > > Changes in GRUB are found at https://github.com/phcoder/GRUB/tree/rust > > Notes on implementation: > > Only i386-pc is implemented right now but it’s not a technical limit, > just others are not implemented yet. > > I changed GRUB to use ET_DYN (.so) binaries as modules instead of ET_REL > (.o). > > I disabled mregparm=3. -Z regparm=3 in Rust generally works but the > calls to memcpy() still uses regparm=0 calling convention. Perhaps it’s a > bug on Rust side, perhaps we need an adapter on our side. > > It’s compiled with panic=abort. Unwinding panics require > rust_eh_personality that isn’t implemented yet. > > src/lib.rs is an example of hello world and grub_lib.rs is a grub-rust > adapter. Ideally they should be in separate crates > > Every module now pulls in rust runtime. Idk how to switch to a shared > runtime > > Consider it more an experiment and request for comments than a working > product. I would be interested to hear any comments. Especially it’s > interesting to hear from Rust folks as to how to make it more idiomatic > Rust. > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
