[quagga-dev 3890] Re: tiny zserv problem on solaris
paul at clubi.ie
Thu Dec 8 19:14:45 GMT 2005
Hi Andrew / Greg,
On Thu, 8 Dec 2005, Andrew J. Schorr wrote:
> I guess I don't understand how that could happen (that a client
> could be interested in a flag that has not yet been abstracted).
> By construction, the clients will have access only to abstracted
It means having to 'keep up' with flags though. E.g. the Linux
link_state stuff is going to have a whole set of flags denoting
> So I would contend that we're dealing with a very finite set of
> flags here, and that it would not be so hard to define IFZ_* flags
> and move forward.
> Given that the IFF_IPV4 and IFF_IPV6 flags are used only inside the
> zebra daemon in solaris-specific code, this suggests another
> alternative: inside the zebra daemon code, carry around 2 sets of
> flags (kernel flags and abstracted zebra flags), but do not
> disseminate the kernel flags to the client daemons (i.e. the client
> daemons receive only the abstracted flags and must rely only upon
ACK, if we do it this way, zebra at least does need to keep the
> So basically, the major flags we care about are: loopback, multicast,
> running, up, pointopoint, and broadcast. Am I missing anything?
Essentially, my thinking is to /not/ abstract the flags, but rather
provide the abstraction in libzebra, through functions. Then the
1. a pile of opaque bits for clients to pass to libzebra and ask
questions about (link working?)
2. containing information from kernel the client knows to look for,
which zebra didn't know about.
Ie I'd like to abstract the flags in the application, through
libzebra, rather than zebra and zserv.
Same difference, slightly less work in zebra, we /will/ provide
abstractions but on the other hand we won't accidently hide
Anyone violently opposed? ;)
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
He who knows others is wise.
He who knows himself is enlightened.
-- Lao Tsu
More information about the Quagga-dev