[quagga-dev 3886] Re: tiny zserv problem on solaris
paul at clubi.ie
Thu Dec 8 13:10:57 GMT 2005
On Wed, 7 Dec 2005, Greg Troxel wrote:
> You are quite right to question this.... In the end, they should
> not be used. I am proposing having both in the protocol so that we
> can transition gracefully. Then, raw kernel flags would only be
> there for dire needs the standardized ones can't yet handle.
Ok, another point of view. While thinking about this yesterday
evening, how it would be done, it seems to me that the vast number of
flags fall into two classes:
1. Well known across all operating systems (IFF_POINTOPOINT, IFF_UP,
2. Specific to one system (e.g. IFF_VIRTUAL on Solaris)
There is then the third, problematic class:
3. Flags common across systems, but differing in meaning. To date,
that's just IFF_RUNNING.
We could abstract all the flags, but then we probably have to export
/both/ the abstracted zebra flags and the raw kernel flags. If we
don't export the kernel flags across zserv, then obviously clients
which are interested in kernel flags which zebra has not yet
abstracted are inconvenienced. Also, for the vast majority of flags
abstraction will be meaningless (cause they fall into 1 (no
abstraction needed) or 2 (there is no way to abstract them)).
So perhaps, rather than fully abstracting the flags, we might instead
abstract /only/ the 3rd class - the only class which needs it?
Ie the only thing we need to do is interpret if_flags/ifi_link_state
and provide abstract link state flags.
What say? :)
On reflection, I've grown a bit uncomfortable about thought of trying
to abstract IFF_ flags.
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
He that composes himself is wiser than he that composes a book.
-- B. Franklin
More information about the Quagga-dev