Date: Wed, 26 Jul 2006 18:37:58 +0200 From: Fredrik Lindberg <fli+freebsd-current@shapeshifter.se> To: gurney_j@resnet.uoregon.edu Cc: freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes Message-ID: <44C79A66.6000204@shapeshifter.se> In-Reply-To: <20060725173924.GR96589@funkthat.com> References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C79A66.6000204>