On Fri, Jan 19, 2024 at 01:05:17PM -0600, Trevor Gross wrote: > On Mon, Jan 15, 2024 at 1:22 PM Kent Overstreet > <[email protected]> wrote: > > > > On Mon, Jan 15, 2024 at 12:10:22PM -0700, Thomas Bertschinger wrote: > > > On Mon, Jan 15, 2024 at 01:45:22PM -0500, Kent Overstreet wrote: > > > > On Mon, Jan 15, 2024 at 10:55:09AM -0700, Thomas Bertschinger wrote: > > > > > I'm leaning towards keeping Make as the primary build tool for now and > > > > > perhaps a future patch can move towards using Cargo. But other > > > > > opinions > > > > > are welcome. > > > > > > > > Let's hold off on that for now. > > > > > > > > I'm planning on pullling the Rust code in bch_bindgen into the kernel > > > > soon, and I want to see how that interacts with the kernel build system. > > > > If there's potential for commonality with the kernel build system, we > > > > might want to take advantage of that. > > > > > > > > (Also, if you're interested in that project, let me know! Getting that > > > > ready for the next merge window is a high priority item, but I have a > > > > lot of high priority items at the moment... :) > > > > > > Sure, I would definitely be interested in helping out with that. I don't > > > want to make any promises regarding timeline, since this combines two > > > worlds--Rust, and Linux Kernel development--that are both still very > > > new to me. But I can certainly give it an honest try :) as long as you, > > > or someone else experienced, can help with any questions I might run > > > into. > > > > Of course :) > > > > Join the IRC channel - irc.oftc.net#bcache, we've got quite a few people > > acquainted with Rust there. > > > > The main thing that needs to be sorted out is that we require a patched > > version of bindgen (since rustc can't yet handle types that are both > > packed and aligned); we need to talk to the rust-for-linux people about > > whether they'll be ok with switching the kernel to the patched bindgen > > until we can get a proper fix into rustc. > > > > Do you have a link to the patches needed? We are wondering if this is > something that could be upstreamed.
The current workaround is to just drop #[repr(align)] if the type is both packed and aligned - but that leads to rustc and gcc disagreeing on the memory layout of certain types; it only works as long as we're not mutating types where this matters from rust code.
