Re: [batadv,v14 5/5] batman-adv: avoid superfluous DAT DHT_PUT additions to local DAT

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Wednesday, 7 October 2026 03:08:03 CEST Linus Lüssing wrote:
> > - [Medium] batadv: UAPI source compatibility breakage via reserved field rename
> 
> I would have thought that for a field called "reserved" it would
> be clear that it'd be subject to change in the future.

To play the devils advocate: But programs would still fail when they 
manually initialize this field to 0.

> Or should I introduce a "struct batadv_unicast_4addr_v2_packet"?

Usually, you have a couple of bytes marked as a reserved array. And then they 
reduce the number of bytes by X and add a new field. You can discuss if this 
is correct or not (because then suddenly the new field would no longer be 
initialized).

But for example, in commit c07d3aede2b2 ("fscrypt: add support for hardware-
wrapped keys") or commit 38a435800945 ("habanalabs: expose device security 
status using info ioctl") or 91233ad71186 ("vhost: support ASID in IOTLB 
API"), exactly your approach was taken.

You could in theory (to make it compile in all situations), also use an 
anonymous union around flags and reserved to ensure the byte can be accessed 
with both names.

To also support your point, please check 
https://docs.kernel.org/dev-tools/checkuapi.html - which also considers 
"reserved" as ok:

 95         # Common padding field names which can be expanded into
 96         # without worrying about users.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]