B.A.T.M.A.N Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Sven Eckelmann <sven@narfation.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org, sashiko-reviews@lists.linux.dev,
	marek.lindner@mailbox.org, sw@simonwunderlich.de,
	antonio@mandelbit.com
Subject: Re: [batadv,v14 5/5] batman-adv: avoid superfluous DAT DHT_PUT additions to local DAT
Date: Wed, 7 Oct 2026 14:15:44 +0200	[thread overview]
Message-ID: <asY38NN2pGa8FICm@sellars> (raw)
In-Reply-To: <5152412.GXAFRqVoOG@sven-desktop>

On Wed, Oct 07, 2026 at 09:24:23AM +0200, Sven Eckelmann wrote:
> 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.

On the other hand I'm thinking they should have memset() the
struct to zero in the first place, instead of manually setting a
reserved field to 0.

Similar to ioctl()'s for instance, where there too you should
memset/zero the full struct, passed argument, I believe, instead of
just zero'ing individual fields as there might be new fields getting
appended in the future.

Interestingly, include/uapi/linux/ethtool.h has an explicit note
for this:

```
  26 /* Note on reserved space.
  27  * Reserved fields must not be accessed directly by user space because
  28  * they may be replaced by a different field in the future. They must
  29  * be initialized to zero before making the request, e.g. via memset
  30  * of the entire structure or implicitly by not being set in a structure
  31  * initializer.
  32  */
```

Which we don't have in batadv_packet.h though. (So technically,
someone could complain about such a rename because we don't have such a note?)

  reply	other threads:[~2026-10-07 12:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 18:50 [batadv,v14 0/5] batman-adv: increase DAT DHT timeout Linus Lüssing
2026-10-06 18:50 ` [batadv,v14 1/5] batman-adv: move local ARP reply code to subfunctions Linus Lüssing
2026-10-06 18:50 ` [batadv,v14 2/5] batman-adv: split DAT cache into DAT cache and DAT DHT Linus Lüssing
2026-10-06 18:50 ` [batadv,v14 3/5] batman-adv: increase DAT DHT timeout Linus Lüssing
2026-10-06 18:50 ` [batadv,v14 4/5] batman-adv: avoid superfluous DAT DHT_PUT if self-candidate Linus Lüssing
2026-10-06 18:50 ` [batadv,v14 5/5] batman-adv: avoid superfluous DAT DHT_PUT additions to local DAT Linus Lüssing
2026-10-07  1:08   ` Linus Lüssing
2026-10-07  7:24     ` Sven Eckelmann
2026-10-07 12:15       ` Linus Lüssing [this message]
2026-10-07 12:38         ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=asY38NN2pGa8FICm@sellars \
    --to=linus.luessing@c0d3.blue \
    --cc=antonio@mandelbit.com \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=marek.lindner@mailbox.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sven@narfation.org \
    --cc=sw@simonwunderlich.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox