Date: Mon, 10 Apr 2000 21:52:49 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Terry Lambert <tlambert@primenet.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Matthew Dillon <dillon@apollo.backplane.com>, Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000410215249.B42765@prism.flugsvamp.com> In-Reply-To: <200004110032.RAA29933@usr09.primenet.com> References: <20000407001929.N80578@prism.flugsvamp.com> <200004110032.RAA29933@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 11, 2000 at 12:32:50AM +0000, Terry Lambert wrote: [ ..snip.. ] > Further, I would suggest the ability to queue an event down, > at the same time posting a read for the next event up, so as > to save 50% of the system calls that would otherwise be > required. [ ..snip.. ] > The point being is that if there is a listener registered, > then attempts to connect are passed with credential information > to the listener. The listener can then make an administrative > policy decision as to whether or not to refuse the request > (e.g. make the "connect" system call return an error, as > something like "EPOLICY", if the demand that would have resulted > in the link being brought up is prohibited by administrative > policy). I understand what you're saying here, but it's a different area in problem space. What you seem to be looking for is essentially a message passing mechanism between the kernel and userland. This is not exactly what the current code is targeted for. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000410215249.B42765>