Re: if_flags

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 26 Jan 2009 23:27:03 -0500 (EST)
    From:        der Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <200901270434.XAA16046%Sparkle.Rodents-Montreal.ORG@localhost>

  | The 4.4BSD sources are not an API spec any more than the NetBSD sources
  | are.

They are, both of them.   They may not be in the form you'd like,
or as accessible or precise as you'd like, but they are a specification,
and they are defining an API (and an ABI).

  | To cite the example at readiest hand in this thread: are the API fields
  | bearing interface flags (eg, struct ifreq .ifr_flags) defined to be
  | unsigned shorts, or are they defined to be some unsigned integral type
  | no larger than unsigned long int, or what?

They are exactly whatever the 4.4 if.h file says they are.   That's the
spec.   Not some other type that might be kind of similar to the one
actually used in the struct definition.   But that exact one.   Change
from short to unsigned short and you've altered the API.

  | And this is not a question that can be
  | answered by inspecting sources - unless there's a comment lurking
  | somewhere that talks about it,

You're assuming that a specification must be written in English.
It doesn't.   Would you be claiming there is no spec if the only
document you could find was written in French?   Or Chinese?
If those languages are acceptable, then why not C?   If anything
it is likely to be more precise, as it has to be interpreted by
compilers, not just the (we hope) more intelligent humans.

Or it may be that you're assuming that it wasn't necessarily intended
to be,a nd perhapd doesn't need to be, as precise as it is, and that may
be true - but once it became the spec, its precision (needed or not)
came along with it - we don't get to ignore bits and just claim that part
doesn't really matter.   Or not unless we're also willing to simply
decide we're going to break conformance.

Now, given all that, this is an area where some API change is
probably acceptable.  We need to care about binary compat via the
syscall interface, but internally I think this is fair game.

We badly need a simple, well defined "interface works" flag,
the way that has been described for FreeBSD and Linux (the
link status NetBSD currently has is better for humans, but much
harder to interpret for software that just wants a working/not-working
status).   Whether that should be IFF_RUNNING or not I don't know,
but if other people have done it that way...    (It is interesting that
nat-snmp did, and I think still does, treat IFF_RUNNING as "admin up"
(ie: what is really IFF_UP) and treats IFF_UP as "working" - then given
that lo0 has no need for IFF_RUNNING we end up with an interface that
net-snmp thinks is administrativey down, but working anyway...)

I have always hoped that there are a few flags that have no logical use
outside the kernel (perhaps IFF_OACTIVE, IFF_RUNNING with its original
meaning, maybe some of the other internal flags that communicate little
useful information to the outside world) that could be moved to a different
flags word without upsetting anyone at all (to keep the API they could
remain defined with value 0 (outside the kernel), so they'd just never appear
to be set to anything that tests them) then those 2 (or more) bits could get
used for more flags where application/kernel interface is needed.   That way
we avoid significant API and ABI changes, but get to add a few extra
essential flags.

I had understood that this kind of decision was made in some kind of
mysterious way as a co-operation between all the BSD's (and perhaps
linux too) which was always beyond my comprehension, so I've never
bothered suggesting it.   But if we're seriously considering playing
around (in even a small way) with ifnet data, then, this would be the
time...

kre