On 23.08.24 01:53, Greg Kroah-Hartman wrote: > 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? That's what I interpreted from the links you provided above, there are multiple invocations of `ANDROID_KABI_RESERVE` and I figured they each can be used to insert a new field. Or can you replace each one by as many fields as you want, as long as the size is still fine? > 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? :) Not with all the other things that you need. I feel like this discussion is dragging a bit on, so we will just ask the Rust folks if they have any suggestions and if they don't we will ask for a solution. We can then get back to this when that's done. It's not like we need this immediately. >>> 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... I don't know if we already have a way, but we will need one if people start writing kabi in Rust. --- Cheers, Benno
