[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251018231126.GS3938986@ziepe.ca>
Date: Sat, 18 Oct 2025 20:11:26 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Vipin Sharma <vipinsh@...gle.com>
Cc: Lukas Wunner <lukas@...ner.de>, bhelgaas@...gle.com,
alex.williamson@...hat.com, pasha.tatashin@...een.com,
dmatlack@...gle.com, graf@...zon.com, pratyush@...nel.org,
gregkh@...uxfoundation.org, chrisl@...nel.org, rppt@...nel.org,
skhawaja@...gle.com, parav@...dia.com, saeedm@...dia.com,
kevin.tian@...el.com, jrhilke@...gle.com, david@...hat.com,
jgowans@...zon.com, dwmw2@...radead.org, epetron@...zon.de,
junaids@...gle.com, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, kvm@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 15/21] PCI: Make PCI saved state and capability
structs public
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.
All the information in the abi headers needs to have detailed comments
explaining what it is and so on so people can evaluate if it is
suitable or not.
But, it is also not clear why pci serialization structs should leak
out of the PCI layer.
The design of luo was to allow each layer to contribute its own
tags/etc to the serialization so there is no reason to have vfio
piggback on pci structs or something.
Jason
Powered by blists - more mailing lists