On Wed, Oct 22, 2025 at 10:45:31AM -0700, David Matlack wrote: > On Mon, Oct 20, 2025 at 4:49 PM Vipin Sharma <[email protected]> wrote: > > > > On 2025-10-18 20:11:26, Jason Gunthorpe wrote: > > > On Sat, Oct 18, 2025 at 03:36:20PM -0700, Vipin Sharma wrote: > > > > > > > Having __packed in my version of struct, I can build validation like > > > > hardcoded offset of members. I can add version number (not added in this > > > > series) for checking compatbility in the struct for serialization and > > > > deserialization. Overall, it is providing some freedom to how to pass > > > > data to next kernel without changing or modifying the PCI state > > > > structs. > > > > > > I keep saying this, and this series really strongly shows why, we need > > > to have a dedicated header directroy for LUO "ABI" structs. Putting > > > this random struct in some random header and then declaring it is part > > > of the luo ABI is really bad. > > > > Now that we have PCI, IOMMU, and VFIO series out. What should be the > > strategy for LUO "ABI" structs? I would like some more clarity on how > > you are visioning this. > > > > Are you suggesting that each subsystem create a separate header file for > > their serialization structs or we can have one common header file used > > by all subsystems as dumping ground for their structs? > > I think we should have multiple header files in one directory, that > way we can assign separate MAINTAINERS for each file as needed. > > Jason Miu proposed the first such header for KHO in > https://lore.kernel.org/lkml/CALzav=eqwtdzfhzli_mwwxgudbrwwqdbxqrzr4tn28ag8zr...@mail.gmail.com/. > > Following that example we can add vfio_pci.h and pci.h to that > directory for VFIO and PCI ABI structs respectively.
Seems like a good idea to me. Jason
