Communications kernel -> userland

Robert Watson rwatson at freebsd.org
Mon Jul 21 11:21:15 PDT 2003


On Mon, 21 Jul 2003, Terry Lambert wrote:

> Robert Watson wrote:
> > Of these approaches, my favorite are writing directly to a file, and using
> > a psuedo-device, depending on the requirements.  They have fairly
> > well-defined security semantics (especially if you properly cache the
> > open-time credentials in the file case).  I don't really like the Fifo
> > case as it has to re-look-up the fifo each time, and has some odd blocking
> > semantics.  Sockets, as I said, involve a lot of special casing, so unless
> > you're already dealing with network code, you probably don't want to drag
> > it into the mix.  If you're creating big new infrastructure for a feature,
> > I suppose you could also hook it up as a first class object at the file
> > descriptor level, in the style of kqueue.  If it's relatively minor event
> > data, you could hook up a new kqueue event type.  You could also just use
> > a special-purpose system call or sysctl if you don't mind a lot of context
> > switching and lack of buffering.
> 
> I like setting the PG_G bit on the page involved, which maps it into the
> address space of all processes.  8-). 

For one of our research projects, here at NAI, we did a fair amount of
userland network code prototyping.  We started out with IPDIVERT, then
pushed down to BPF using a partial network stack in userspace.  We've
found it's a lot easier on competent network developers who are unfamiliar
with the FreeBSD kernel code, not to mention easier on debugging.  We
never got so far on that project as to do shared memory between the kernel
and userspace, but I know that that's been done by at least a couple of
companies at various points to reduce copying and context switch costs for
userspace test frameworks.  One of the things I'd really like to see if
some decent "throw packets between kernel and userspace" primitive bits,
such that the kernel has a useful and logical way to expose buffer data
into directly mapped user pages, and an appropriate notification and
management system to reuse memory, etc.  Something that looks a bit like
the relationship between kernel device drivers and devices when it comes
to DMA management.  Do you know if any such framework exists? 
(Specifically targetted at exposing network packets...)  (Ideally not
requiring privilege in the user process, nor involving nasty integrity or
confidentiality problems :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories




More information about the freebsd-hackers mailing list