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

Paul Jakma 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,
    etc.)

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.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
He that composes himself is wiser than he that composes a book.
 		-- B. Franklin



More information about the Quagga-dev mailing list