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

Miles Nordin carton at Ivy.NET
Mon Sep 13 18:37:03 BST 2004


>>>>> "ajs" == Andrew J Schorr <aschorr at telemetry-investments.com> writes:
>>>>> "vj" == Vincent Jardin <Vincent.Jardin at 6wind.com> writes:

   ajs> If IFF_RUNNING is not
   ajs> conveying any useful info on BSD, then shouldn't you be able
   ajs> to simply load the
   ajs> ifm-> ifm_data.ifi_link_state value into the IFF_RUNNING flag?

I tried that.

1. 'show int' doesn't match ifconfig.  principle of least surprise.
   sysadmins will expect RUNNING in ifconfig to show link-detect, and
   it won't.

2. flags are always copied all at once.  Now I have to hunt down all
   places where flags are copied and make it more complicated than
   simple asignment, many not involving RTM_IFINFO.  prone to
   regression if someone obeys intuition and adds an uncomplicated
   assignment statement.

ifm_data is also copied into ifp.  A reasonable thing to do would be
just read from that copy.  But that is also used by quagga for
statistics, and I didn't check how statistics are handled---sometimes
one might for example want to build histograms by comparing local
statistics to kernel statistics that have to be done at every
link-detect change, or there are calls to if_up() that trigger events
when the local link-detect copy differs from the kernel copy which
will be skipped by simple assignment ifp->stats = ifm->ifm_data.
done carefully it is maybe better to read link-detect out of quagga
ifp->stats on BSD, but it must be careful, and maybe it's not better.

I was not intending to spend so much time on this---just trying to
make it work for me without future regressions for others.  And my
defense is much longer than patch.  many other serious patches are on
the table here.  silly.  I think I'll drop this.

hrm.  ok though,...Really the far more serious problem is that many
NetBSD network drivers change the state of ifm_data.ifi_link_state
without generating a route socket message.  This is pretty clearly
broken.

The presence of quagga's 'link-state' config option suggests to me
this is a common problem.  If IFF_RUNNING merely sometimes was
always-1 there would be no need for the quagga config option, but the
problem I have here is, on network drivers that don't properly
generate messages when updating ifi_link_detect, quagga's idea of
link-detect gets out of sync with the kernel.  This breaks routing, so
I suspect that's why the quagga config option is there.

    vj> IFF_RUNNING can be used (and should be used) for the link on
    vj> BSD too.

As I said before, BSD link states have three states, not two, and
can't be overloaded onto a 1-bit flag.  The LINK_UNKNOWN state is 0,
so you can safely memset-0 structures and get reasonable defaults.
It's a good API.

    vj> It is the standard approach.

well, it seems safe to assume IFF_RUNNING is derived from BSD back
when everyone imported the BSD stack.  I'm not sure when you guys
changed it to mean something else and then decided your way was
standard, but, seriously,

What standard?  If there is really a standard, I will file a
standards-conformance PR with NetBSD.  Otherwise, BSD is a little
sensitive about being asked to conform to Linux APIs as if Linux were
a standard.  ``Standard'' means something very different from
``popular,'' and standards-conformance to POSIX and X/OPEN is
documented at the bottom of most BSD manpages and is taken quite
seriously.  I understand your OS is also good and works well and has
good reasons for its design decisions, and people do ask for such
changes all the time.  But it is really not appropriate. :(

Anyway, back on-topic, I think it's also not pragmatically
urgent---Quagga accomodates the BSD API easily.

-- 
Le fascisme est la dictature ouverte de la bourgeoisie.
		-- Georg Dimitrov



More information about the Quagga-dev mailing list