From owner-freebsd-current@FreeBSD.ORG Wed Jul 26 16:38:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C53E016A4E1 for ; Wed, 26 Jul 2006 16:38:06 +0000 (UTC) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F94B43D49 for ; Wed, 26 Jul 2006 16:38:05 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 919131A734; Wed, 26 Jul 2006 18:38:03 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67690-03; Wed, 26 Jul 2006 18:38:02 +0200 (CEST) Received: from [192.168.1.91] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 8D2321A6B2; Wed, 26 Jul 2006 18:38:02 +0200 (CEST) Message-ID: <44C79A66.6000204@shapeshifter.se> Date: Wed, 26 Jul 2006 18:37:58 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.2 (X11/20060423) MIME-Version: 1.0 To: gurney_j@resnet.uoregon.edu References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com> In-Reply-To: <20060725173924.GR96589@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 16:38:06 -0000 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