At Tue, 21 Apr 2015 17:35:02 +0100, Mark Brown wrote:
On Tue, Apr 21, 2015 at 05:23:36PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
That's sounding like an awfully small number if we're trying to be infititely future proof (obviously the default value for that is 640k!). We'd also need to go through and give *all* the structures padding. How about just adding length fields instead with a rule that if the structure is bigger than you know about just ignore anything at the end?
In theory, having only "abi" field should be enough, as we can know the size predefined for each ABI version. But I agree that it'd be friendlier for a parser if the header itself declares its size, e.g. via a header_size field or embedding the size into some check field like ioctl.
The trouble with the ABI version information is that it tells new kernels how to handle old tables but old kernels will have no idea what to do with new firmwares.
If the given data is incompatible, kernel can't handle it anyway. So, ideally speaking, the ABI version should contain two things: the binary compatibility as a major version and the detailed data definition as a minor version. If the major version is same, an old kernel can assume that the data has the same size and read it as is. If it's greater than the supported major version, the kernel should return the error.
But, again, I'm for having the header size, too. I just explain here how abi version field could be used in theory.
Takashi