DragonFlyBSD

There's been an IRC conversation recently regarding that. FreeBSD
defines a EVFILT_NETDEV filter, which can have one of the following
event bits set: NOTE_LINKUP, NOTE_LINKDOWN, NOTE_LINKINV. It's a quite
clean interface. I don't know why OpenBSD chose to do it diferently.

Yah.

I think your changes do affect all mii aware NICs (almost all modern NICs :)

I think bridge's link state change support has already been in place,
but is commented out.

For current vlan implementation, I am afraid you will have to go
through all vlan ifaces to locate vlan ifaces backed by the specific
state changing NIC.

BTW, this patch looks OK to me.

Best Regards,
sephe

I think hasso's patch is fundamental parts for the knote
implementation you mentioned above.

Best Regards,
sephe

Yes, I only read the patch after I finished writing my first mail :/

After reading some code and discussion in IRC ...

These are different things. AFAICS EVFILT_NETDEV is just another event
notifying mechanism. Does anybody uses these link events in FreeBSD at all?
All BSD's do related work in if_link_state_change(), only FreeBSD schedules
it for later processing to avoid various locking issues (how we should do
regarding this?) and all actual work is done in the do_link_state_change().
So, in this regard OpenBSD and FreeBSD are not different.

What OpenBSD does it that it allows various subsystems register various
callbacks to the interfaces and the code in if.c is shorter and simpler.
This is coding issue, not the behavioural one. For example instead of the
mass of ifdefs etc if_link_state_change() looks trivial:

void
if_link_state_change(struct ifnet *ifp) {
rt_ifmsg(ifp);
dohooks(ifp->if_linkstatehooks, 0);
}

So, I don't have modern NICs, seems ;(.

I will look at bridge stuff later probably.

Let's change the VLAN implementation as well then. VLAN stuff is close to
top in my priority list anyway.

Thanks.

:Announcing link state changes to the userspace via route socket is critical
:to get routing related applications to work correctly - routing protocols
:are most important, but other applications might benefit from it as well.
:
:This code is adapted from OpenBSD and is only the first basic step in path
:to get correct support. Only em(4) is tested because I don't have hardware
:to test others, although bge(4) might get my attention as well in the
:future.
:
:There is one fundamental problem I'd like to get feedback about from
:developers - how to make various kernel stuff react on link state changes?
:For example various interfaces which are somehow attached to the interface
:(bridges, carp, vlans etc) should react. Ideally routing table should react
:as well (yes, no BSD or Linux kernel does that yet, but they should).
:Personally I like the idea of the hooks OpenBSD uses, but as I'm not very
:familiar of DragonFlyBSD, my personal opinion might be very far from good
:solution ;).
:
:regards,
:
:--
:Hasso Tepper

It won't build straight out of the box since a number of other
    drivers are still using the existing if_link_state_change() function
    call.  I kinda prefer the if_link_state_change(ifp, state) API 
    rather then the ifp->if_link_state = ...; if_link_state_change(ifp) API.

I agree with the work, though... I'd like to see this in DragonFly
    once it gets cleaned up a bit.

There seem to be a few other changes mixed into your patch.  What's
    the baudrate part of the patch?  (I like it, I'm just not sure how
    its related to the linkstate work).

-Matt

It builds for me, there is no existing if_link_state_change(ifp, state) call
in DragonFly. FreeBSD has it, but all cases in DragonFly are either
commented out in DragonFly or #defined to void(0). I don't agree with
FreeBSD though. It's not only about link up/down, but also about interface
speed changes. With my patch this case is handled as well (as it is in
OpenBSD and NetBSD).

This is about the case to call if_link_state_change(ifp) if interface speed
(baudrate) changes.

regards,

If there are no objections, I will commit this patch two days later.

Best Regards,
sephe

Does this make it possible for dhclient to re-send a request when link goes up (if there are DHCP'd interfaces)?

:On 3/16/07, Hasso Tepper <hasso@estpak.ee> wrote:
:> Announcing link state changes to the userspace via route socket is critical
:> to get routing related applications to work correctly - routing protocols
:> are most important, but other applications might benefit from it as well.
:
:If there are no objections, I will commit this patch two days later.
:
:Best Regards,
:sephe
:
:--
:Live Free or Die

Sounds good, I'm all for it.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Committed! Thanks!

Best Regards,
sephe