Date: Mon, 21 Jul 2003 10:45:46 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Robert Watson <rwatson@freebsd.org> Cc: Marc Ramirez <marc.ramirez@bluecirclesoft.com> Subject: Re: Communications kernel -> userland Message-ID: <3F1C26CA.9F2AE361@mindspring.com> References: <Pine.NEB.3.96L.1030720125403.91635A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F1C26CA.9F2AE361>