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

Greg Troxel gdt at ir.bbn.com
Wed Dec 7 15:21:59 GMT 2005


Paul Jakma <paul at clubi.ie> writes:

> On Wed, 7 Dec 2005, Greg Troxel wrote:
> 
> > It's the same issue, but this is another case, where we really want
> > to have a predicate in the daemon "does the interface have the foo
> > property" and that has to check different kernel flags on different
> > operating systms.
> 
> Aha. You're saying we should abstract flags we know and care about?
> How far do we take it?

Yes, and all the way.  The whole point of zebra the daemon is to
abstract the OS forwarding and interface behavior.  In "zebra flags"
(vs. kerrnel flags, which we can make available for when really needed
even though an abstraction violation), we define semantics of the
flags.  zebra maps kernel flags into our defined semantics.  Then
daemons just check the zebra flags of interest.

> Could we use this abstracted zebra flags for link-state too? Or keep
> it seperate? (Probably should be seperate, given link-state would be
> better represented by a number/enum than a set of independent flags).

abstract link state has to be able to represent all that we care about
from any reasoable OS.  Linux and I think Solaris has "I'm sure it is
down" and "It's up or I can't tell".  BSDs have "I can't tell", "It's
up" and "It's down".  So we need 4 values to represent this, and then
predicates that select the states of interest.  Whether it is a
separate variable or some bits in an abstract flag word is a minor
issue; this feels like flags, just multivalued, so I'd use several
adjacent bits, and probably reserve 4 to get 16 codepoints since this
seems likely to get more complex.


Thinking more, perhaps rename the existing variable from flags to
kernel_flags and add zebra_flags as unused.   Dave Young is the only
one who'll have to cope, and he said he didn't mind (and I bet would
like link detect on BSD).

-- 
        Greg Troxel <gdt at ir.bbn.com>



More information about the Quagga-dev mailing list