Re: tap(4) interface management

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

> Extending the tap driver would be less invasive but unfortunately the
> tap IO is carried out on a file descriptor so is no way (?) to do out
> of band communication (socket control messages would have been great
> for this), the best I can come up with is to have an ioctl enable
> (eg) SIGUSR to be raised on informational changes and have the daemon
> check.

> thoughts and suggestions?

I would be inclined to do it in the tap driver.  I would probably do
this by providing a tap-specific ioctl which puts it into a mode where
data, at least tap->user, has a header that (possibly among other
things) allows userland to distinguish between packets and other
ancillary data.  The default, of course, would be no header and no
out-of-band data.

Whether the mode applies to the fd or to the tap device is an open
question.  The former makes more sense; I would expect the latter to be
easier to do.  In practice I don't expect there's much difference.

Another possibility would be a (tap-specific) ioctl which opens and
returns another file descriptor for the out-of-band data.  I'm not sure
which of these two I prefer - probably whichever looks easier to
implement.

/~\ 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