[quagga-dev 1508] Re: link detection on NetBSD

Paul Jakma paul at clubi.ie
Tue Sep 14 15:53:09 BST 2004


On Tue, 14 Sep 2004, Greg Troxel wrote:

> I think what you are saying is that 'show interface' should follow 
> Cisco CLI behavior.  Historical BSD behavior is not that 'RUNNING' 
> shows whether there is a link detected.

Right, but it'd probably be a good idea to make it so within zebra. 
The daemons need something to test link-state against and IFF_RUNNING 
seems the simple choice. Indeed, in the ZServ messages, we should 
change this to a set of Zebra specific flags. ZEBRA_IFF_RUNNING, 
etc..

> Right now the code has flags variables that are simply copies of 
> the kernel flag state.  That's a very sane thing to do, but I see 
> where it might be an issue if we want to have OS-independent code 
> process flags which have diverged from the original BSD semantics 
> [1].

Right.

> Because of differing semantics, I think the best thing to do is to 
> store all the kernel information as-is (which I think we do now), 
> and to write functions that take the interface struct and return 
> link state.  Then the CLI code, or whatever else cares, can use 
> those functions to decide whether to print out RUNNING on show 
> interface, or to treat an interface as up --- an entirely separate 
> issue from whether the host OS kernel has the RUNNING bit set. 
> These functions can then be ifdefed for various behaviors so they 
> use RUNNING on OSes that use RUNNING for this, and the BSD link 
> detect info for systems that do it that way.

I'm leaning towards:

- Leave the flags alone
- define zebra if flags (to send to daemons)
- abstract the various link info mechanisms available into
   a struct quagga_link_info
- let each platform populate that to suit
- toggle the zebra specific if_flags to suit, and send interface
   update messages accordingly.

> To nitpick a bit, Linux and Solaris doing it still doesn't make it 
> a standard, just more common.

Sure, I didnt mean to imply it was a standard. Just there is no 
standard, and IFF_RUNNING is one (simple) way.

> What do Linux and Solaris do for hardware that doesn't return 
> link-detect information (i.e., for cases when netbsd returns 
> unknown?)

Then IFF_RUNNING is always held. Which makes sense.

> Information on FreeBSD and OpenBSD behavior, or anything else, 
> would be interesting - the important thing is that the abstractions 
> we implement be sane for all underlying ways of doing things.

Right.

> --------------------
> [1] TCP/IP Illustrated, Volume 2, Figure 3.7 on p. 67 says that
> IFF_RUNNING means 'resources are allocated for this interface'.

That's the comment in linux and Solaris if.h too ;)

I guess the rationale could be: If link is gone, then one of the 
required resources is not "allocated".

> I looked at NetBSD's src/sys/dev/ic/i82557.c, and RUNNING is used to
> denote that the card has been programmed with dma descriptors, etc.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Windows Tip of the Day:
Add DEVICE=FNGRCROS.SYS to your CONFIG.SYS file.



More information about the Quagga-dev mailing list