Re: if_flags

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

[cube quoting me quoting joerg]
>>> If you want to make if_flags itself 32bit, you have to deal with
>>> endianess, don't you?
>> I can't see why; [...]
> I'd say it matters for binary compatibility.

Ooh, good point.  (I knew there'd be something I hadn't thought of.
Binary compat often fails to occur to me because I always build from
source.  It takes rare cases like running under a new OS rev before
rebuilding everything for me to run into binary compat issues.)

I guess growing if_flags (as opposed to adding if_flags2 or some such
the way gdt wrote of) would mean versioning all the ioctls, sockopts,
sysctls, whatever, that handle IFF_ bitmasks, whether in struct ifnet
or not.

I guess I'll do it privately, then, same as I did for 1.4T, and ignore
the binary compat issue because I'll be rebuilding everything anyway.
If we can come to a consensus on a right way for the main tree, perhaps
my work can be a starting point....

[gdt]
> Are you thinking of bringing this up with the FreeBSD, OpenBSD and
> Dragonfly folks?

I haven't been, not yet.

> It would be nice to keep the API the same among *BSD.

The API for interface flags is rather ill-defined, is my impression.
It is not clear to me whether there is a spec that defines the type of
fields that hold IFF_* interface flags; as I recall there were very few
things that needed to be grown when I did this to 1.4T, so what little
evidence I have indicates that the de-facto API wouldn't change much.
(I've never seen anything like a real API spec for this stuff; I don't
know whether this is because one doesn't exist or because I just
haven't looked in the right place.)

The ABI is another story.  See above for that.

> In my private work, I added a flag SEMIBROADCAST [...]

I wanted to add NOFWFROM and NOFWTO, to provide per-interface control
over packet forwarding (what net.inet.ip.forwarding and
net.inet6.ip6.forwarding control on a per-system basis, basically).
These are two of the flags whose addition prompted my growing if_flags
on 1.4T.  (The others are BPFONLY and DOT1Q, the former meaning "call
bpf but don't do any further receive processing" for snooper interfaces
that should never ever receive packets except via bpf, the latter for
my vlan tagging support.)

I have looked closer, and the immediate need for them has evaporated.
But I still think if_flags should grow; having no room for expansion is
a Bad Thing. :)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B