Re: tap(4) interface management

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I would be inclined to do it in the tap driver.  I would probably do
>> this by providing a [] mode where data, at least tap->user, has a
>> header [...]
>> Another possibility would be a (tap-specific) ioctl which opens and
>> returns another file descriptor for the out-of-band data.
> I think you can do all that using tap-specific kqueue filters.  (See
> kqueue(2), kfilter_register(9) and knote(9).)

Probably.  I see no particular reason to prefer either over the other,
unless your userland code design would prefer the file descriptor
interface over the kqueue interface, or vice versa.  Either way, some
kernel support needs to be written, and code that depends on it will be
nonportable to other OSes.  I'd probably go with the fds, if only
because they're easier to backport, but since I'm probably not going to
be the one doing the work, that doesn't mean much.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B