Re: Extending EVFILT_NETDEV to support ip-address changes

John-Mark Gurney wrote:
> 
> Looks basicly good, though you will need to rethink how the filt_netdev
> handles the hint.. since right now it just sets kn_data to whatever
> hint is..  This is fine when it was simply one of NOTE_LINK{UP,DOWN,INV},
> but now that you have an extra flag, the NOTE_DELADDR could make an
> app miss the LINK status if it was looking at data instead of fflags..
> 
> Plus, are you sure everyone that is using NOTE_LINK* are treating them
> as a bit mask?  maybe we need to redefine NOTE_LINK* as a mask plus set
> of values, since each of the NOTE_LINK* can only be set once...  but
> the NOTE_ADDR{NEW,DEL} should probably be flags...
> 
> We may want to reverse the naming to NOTE_ADDR{NEW,DEL} so that we have
> the more generic first before the more specific...  similar to NOTE_LINK*...

The documented way of using EVFILT_NETDEV according to kqueue(2) is to
obtain the status from fflags, but as it apparently sets data too
somebody is using it, that's for sure.

Users of EVFILT_NETDEV are required to pass a mask of
NOTE_LINK{UP,DOWN,INV} in fflags with the initial kevent call, otherwise
no events will fire.

What if we add NOTE_ADDR{NEW,DEL} as bit masks and change filt_netdev to
only set kn_data when a monitored event occurs instead of just setting
it regardless of if the event is being monitored or not.
If we also restrict the values of kn_data to NOTE_LINK{UP,DOWN,INV},
existing applications shouldn't break as they would only receive the 
events they subscribed to and both data and fflags would be
intact. NOTE_ADDR{NEW,DEL} would be obtain only through fflags and
kn_data would be left as it is in these cases (0 with EV_CLEAR set).

What I'm thinking of is something like this for filt_netdev

     if (kn->kn_sfflags & hint) {
         kn->kn_fflags |= hint;
         if (hint & (NOTE_LINKUP | NOTE_LINKDOWN | NOTE_LINKINV))
             kn->kn_data = hint;     /* current link status */
     }

 >
 > Suffice it to say, this cannot be back ported to RELENG_6 due to API
 > breakage...
 >

Doing it this way shouldn't break the API, as no fields would be touched
because kn_sfflags & hint would fail for ADDR{NEW,DEL} on existing
applications as they would only be subscribed to one or more of the
NOTE_LINK{UP,DOWN,INV} events.
But maybe I'm missing some rare edge case...


Fredrik Lindberg