Date: Mon, 21 Jul 2003 14:20:40 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Marc Ramirez <marc.ramirez@bluecirclesoft.com> Subject: Re: Communications kernel -> userland Message-ID: <Pine.NEB.3.96L.1030721141622.97358C-100000@fledge.watson.org> In-Reply-To: <3F1C26CA.9F2AE361@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030721141622.97358C-100000>