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 - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "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