On Tue, Apr 11, 2023 at 11:36:48AM -0700, John Moon wrote: > > > > > > Others do not seem to be intentional: > > > > > > Addition/use of flex arrays: > > > - include/uapi/linux/rseq.h (f7b01bb0b57f) > > > - include/uapi/scsi/scsi_bsg_mpi3mr.h (c6f2e6b6eaaf) > > > > That is not a breakage, that's a tool problem. > > > > > Type change: > > > - include/uapi/scsi/scsi_bsg_ufs.h (3f5145a615238) > > > > Again, not a real breakage, size is still the same. > > > > Would you find the tool more useful if it simply filtered out all instances > where the size of the type did not change? This would filter out the > following which the tool currently flags: > > - enum expansions > - reserved field expansions > - expansions of a struct with a flex array at the end > - type changes > - re-ordering of existing members > - ...others? Obviously not, as some of those are real breakages, and some are not at all. Please understand what is an abi breakage. Adding new enums is not. Using a reserved field is not. Reording existing members IS. > These changes aren't _always_ safe, but if you assume the kernel developer > is doing something reasonable, then maybe it's okay. Maybe we could hide > these checks behind something like a "--pedantic" flag? Again, no, that list above has totally different things in it, some are completly safe, others totally break the abi. Do NOT lump them all together as that is wrong. thanks, greg k-h
