[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tap(4) interface management
On Wed, 13 May 2009, Quentin Garnier wrote:
> 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.
Mm, this sounds interesting and it would actually be quite simple to
process a header (in btpand) as its already doing the ethernet header.
> > 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.
I think there is no difference because there can be only one fd per
device with tap anyway
> > 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 didn't think of that either, it would be easier to pass complete
information on a separate descriptor (and would save a bunch of fiddling
around trying to fetch information) though it starts to look just like
route(4) but private to tap(4)
> I think you can do all that using tap-specific kqueue filters. (See
> kqueue(2), kfilter_register(9) and knote(9).)
I guess so, though I'm not desperately keen on that as btpand is using the
event(3) API and although that does internally use kqueue (by default), I
don't think there is a way to add events that would trigger from a custom
Main Index |
Thread Index |