seems to me like you've re-invented the concept of variable array?

this is exactly like we've done in other places e.g. with
uint32_t data_size;
uint8_t data[];

In both cases, this is a final change to the structure, you cannot add anything after the variable array, so it'd be wise indeed to keep some reserved space before the variable array.

uint8_t data[] is an incomplete array type.

A variable array is something like int n; uint8_t data[n] instead.

When it's the last member of a structure, an incomplete array type is more specifically called a flexible array member.

Sorry to be pedantic but the right terms are needed when searching documentation and more generally looking for information. For instance information about best initialization practices (see previous sizeof/memset discussion) or that the kernel is now VLA-free
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA
https://lwn.net/Articles/749064/

Plus memory (mis)management is where most security issues lie so some pedantism can't hurt there :-)

thanks for being pedantic @marc-hb, my point remains that it's probably better to be explicit about data structures than implicit. There are tools that will detect that a flexible array is the last in a structure, if it's not even declared we'd be writing them off.

seems to me like you've re-invented the concept of variable array?

this is exactly like we've done in other places e.g. with
uint32_t data_size;
uint8_t data[];

In both cases, this is a final change to the structure, you cannot add anything after the variable array, so it'd be wise indeed to keep some reserved space before the variable array.

No, it is not the flexible array here, it means explicit one uint32_t member. It used to be reserved[2] and is reserved[1] after .core is introduced.

I think the reason that keeping these 'reserved' member is to avoid bumping MAJOR frequently, once they are used up, we have to extend it with a MAJOR bump when any new member being added.

uint8_t data[] is an incomplete array type.

A variable array is something like int n; uint8_t data[n] instead.

When it's the last member of a structure, an incomplete array type is more specifically called a flexible array member.

Sorry to be pedantic but the right terms are needed when searching documentation and more generally looking for information. For instance information about best initialization practices (see previous sizeof/memset discussion) or that the kernel is now VLA-free
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA
https://lwn.net/Articles/749064/

Plus memory (mis)management is where most security issues lie so some pedantism can't hurt there :-)

@marc-hb thanks for the details! I somehow completely missed the "get rid of VLAs" movement (shame). I'm wondering though: those articles use the expression "VLAs within structures" - are they referring to structures declared within functions like

void foo(int x)
{
	struct {
		int a[x];
	} b;

? or do they mean what you call incomplete / flexible arrays?

I'm wondering though: those articles use the expression "VLAs within structures" - are they referring to structures declared within functions like

Yes, the former (gcc abomination).

There are a number of differences between Variable Length Arrays and Flexible Array Members. I believe the simplest to remember and also most relevant is:

1. The variable memory of all VLAs is automatically allocated an de-allocated at runtime by code automatically added by the compiler.
2. You must manage the changing memory of Flexible Array Members all by yourself.

I didn't know about gcc VLAs in struct, I read about them today. While plain VLAs were bad, gcc VLAs in structs raise Linus' language to yet another level:
http://thelinuxjedi.blogspot.com/2014/02/why-vlais-is-bad.html
So gcc VLAs in struct are a much worse form of standard VLAs with no relation to standard Flexible Array Members. The terminology is consistent, let's stick to it.

As opposed to all VLAs, Flexible Array Members (= what Pierre actually suggested) are totally welcome in the kernel and a great replacement for 0-sized arrays (bad) or 1-sized arrays (a catastrophe)
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.8-Flexible-Array-Member

PS: maybe not so pedantic after all? ;-)

Is it possible that flexible arrays in IPC can be moved by also having an offset member which says where the array is beginning? This way you don't need to add reserved fields before the array itself, but IPC itself must be aware of this (and made slightly more complex due to it) so it can fill in those intermediate fields with zeros if necessary.