[quagga-dev 1508] Re: link detection on NetBSD
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,
> 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
> 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
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.
>  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.
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
Windows Tip of the Day:
Add DEVICE=FNGRCROS.SYS to your CONFIG.SYS file.
More information about the Quagga-dev