[quagga-dev 3889] Re: tiny zserv problem on solaris

Paul Jakma paul at clubi.ie
Thu Dec 8 16:39:48 GMT 2005

On Thu, 8 Dec 2005, Greg Troxel wrote:

> Another way to say this is "according to the original 4.4BSD semantics".


> This has been extended on one system.  When some other system adds 
> IFF_VIRTUAL, and doesn't clone the Solaris semantics, then this 
> will turn into case 3.


I'm guessing this is unlikely, at least in sense of a post-BSD flag 
being added with same name and /similar/ (but still different) intent 
to one existing on another system. Ie I don't think there's any 
co-ordination of flags any more.

> Plus link detection, which is really a flag.

It's a state though.

>  This is the case where some systems have deviated from the 
> original 4.4BSD semantics.  It's a reasonable deviation, because 
> the original IFF_RUNNING flag wasn't meaningful in user space.

> The original 4.4BSD flags design mixes kernel use and communication to
> routing daemons in the same set of flags.  In 2005 we view that as a
> defiency, but way then it was fully adequate and simple.


Linux is changing this a bit btw; AIUI, they're going to keep 
IFF_RUNNING to mean 'completely up' but add additional flags to 
clarify different link/carrier states.

> True, but I see this as "clients which have not yet been updated to 
> use abstract flags and accessor functions".

> Here I disagree.  As soon as FooOS arrives and has a different way to
> represent the same concept, flags in category 1 move to category 3.
> Essentially, I claim that category 3 is the only stable state.

> I would be perfectly happy to adopt ZIFF_UP to mean what IFF_UP 
> means in 4.4BSD.  Those systems that haven't deviated (in this 
> case, all known ones) will simply set ZIFF_UP if IFF_UP is in 
> kernel flags.
> Now, one can say this is silly, but it prevents the zserv protocol
> from needing to change when something else comes along.

> I think the second class needs it too.  The end goal, in my view, 
> is to have no code in any daemon that tests a flag explicitly. 
> Rather, it should use if_foo functions that ideally test abstract 
> flags, and if necessary have os-dependent ifdefs.


> Still, I think the "flags don't need abstracting" argument is 
> really a reflection that there hasn't yet been divergence in some 
> areas.

Right, I fully agree with you btw.

Essentially, what I'm proposing is a slight modification in /how/ we 
provide the abstraction. I'm saying:

- leave the if flags completely alone, provide them as
   the unadulterated kernel flags in zserv.

- provide abstracted flag/state fields for certain things which may
   or may be derived from the kernel flags, according to system.
   ie the link/carrier state.

- provide the abstraction in libzebra through convenience functions.


That way we get everything:

- weird clients still get the raw flags, should they happen to be
   curious about some odd flag zebra doesn't know about[1]

- we don't have to maintain a kernel<->zebra flags map

   (my fear here is that: it'll be redundant mostly, but worse we
    might eventually see a divergence that can not be nicely abstracted with
    just flags. In which case we'd have to provide additional things
    anyway outside of flags)

- normal clients get fully abstracted semantics simply by feeding a
   struct interface (derived from zserv) to an abstract set of
   libzebra functions.

Ie. leave the kernel flags 'raw', but they should never be used by 
clients wishing to be abstract. However, the simple fact they're 
there means a client /could/ look at the flags, should it happen to 
know more about them than Quagga.

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
As Zeus said to Narcissus, "Watch yourself."

More information about the Quagga-dev mailing list