tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tap(4) interface management

On Wed, May 13, 2009 at 10:16:58AM -0400, der Mouse wrote:
> > 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.

I think you can do all that using tap-specific kqueue filters.  (See
kqueue(2), kfilter_register(9) and knote(9).)

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgp3xhKHjwJka.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index