On Thu, Aug 22, 2024 at 12:00:15PM +0000, Benno Lossin wrote: > > Here's one example in the android tree where 4 64bit fields are reserved > > for future abi changes: > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/fs.h#421 > > > > And here's a different place where a field is being used with many > > remaining for future use: > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1379 > > > > And also, we want/need lots of other space reservation at times, look at > > how "Others" can get access to reserved areas in structures that need to > > be done in an abi-safe way: > > https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1375 > > Let me correct myself, it's only possible to replace one `KAbiReserved` > by one new field. You can have as many fields of type `KAbiReserved` as > you want. The thing that you can't do is replace a single `KAbiReserved` > field by multiple (well you can, but then you have to change the sites > that use it). That's odd/foolish, why would that be the case? Isn't that exactly what a union is for? How are you going to know ahead of time what size types to save space for? All we really want to do here is "pad out this structure by X bytes" and then later "take X bytes to represent this variable" at a later point in time. Surely rust can do that, right? :) > > All of this also needs to be possible in any structures that are > > exported by rust code if vendors want to have a way to track and ensure > > that abis do not change over time, just like they can today in C code. > > All of those structs need to be `repr(C)`, otherwise they don't > have a stable layout to begin with. Do we have any way to enforce at build time that exports from rust code are in this format to ensure that this will work properly going forward? I guess someone is going to have to write the first api in rust that actually gets used before we worry about this... thanks, greg k-h
