Re: git: 9404c479946c - main - pci_user: Report NUMA domain

> For future reference: you didn't need to bump to a new number for the ioctl
> since the size of the argument is encoded in the ioctl as well.  This
> feature of ioctls also means that we generally don't add padding (as you did
> in the followup commit) as you will naturally get a new ioctl cmd value
> anytime you add more fields in the future.  This avoids the one point Warner
> raised in the review about how do you define the semantics of the padding
> as that approach defers reserving space in the structure until the semantics
> of that space is known.

Hey John,

I just took another look at this and understand your point about not
needing to bump the ioctl number, but am struggling to see why that
would remove the need for padding.

The point of the padding was to minimize the in-kernel churn needed
when adding new members to struct pci_conf. Without it, adding a new
member means we need to account for the old ioctl (with the old length)
in every switch statement in pci_user.c and there are a lot.

The only solution I can think of to get around this is to switch on the
IOCGROUP of every command and copy out IOCPARM_LEN number of bytes.
Then modifying pci_conf wouldn't require an additional case for every
switch statement. There may be a reason, that I'm not aware of, for why
we don't already do this. Perhaps this is what you were thinking?

Thanks,
Jake Freeland