Date: Tue, 25 Jul 2006 13:58:42 -0700 From: Julian Elischer <julian@elischer.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Fredrik Lindberg <fli+freebsd-current@shapeshifter.se>, freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes Message-ID: <44C68602.50105@elischer.org> 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:
>Fredrik Lindberg wrote this message on Tue, Jul 25, 2006 at 14:54 +0200:
>
>
>>I have a suggestion to add support for ip-address changes to the
>>kqueue (EVFILT_NETDEV) system.
>>The infrastructure for EVFILT_NETDEV is already in place and this
>>only introduce NOTE_NEWADDR and NOTE_DELADDR and minor modifications
>>to the interface ioctl handler.
>>
>>The purpose is not to replicate the functionality of the
>>routing socket, but to provide a low overhead mechanism for
>>monitoring a given interface for address changes.
>>No information about the event is sent through the kqueue system,
>>instead it will be up to the caller to query the system (if wanted)
>>to obtain information about the current state of the interface
>>that is being monitored.
>>
>>I have attached a suggested patch, any thoughts?
>>
>>
I may be wrong but doesn't an address change already trigger a routing
socket event?
>
>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*...
>
>Suffice it to say, this cannot be back ported to RELENG_6 due to API
>breakage...
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C68602.50105>