From owner-freebsd-arch Mon Apr 10 19:51:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 59E0337B887 for ; Mon, 10 Apr 2000 19:50:39 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA06751 for ; Tue, 11 Apr 2000 04:50:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA06715 for freebsd-arch@freebsd.org; Tue, 11 Apr 2000 04:50:34 +0200 (CEST) Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 54FD037B887 for ; Mon, 10 Apr 2000 19:49:59 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id VAA44654; Mon, 10 Apr 2000 21:52:49 -0500 (CDT) (envelope-from jlemon) Date: Mon, 10 Apr 2000 21:52:49 -0500 From: Jonathan Lemon To: Terry Lambert Cc: Jonathan Lemon , Matthew Dillon , Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000410215249.B42765@prism.flugsvamp.com> References: <20000407001929.N80578@prism.flugsvamp.com> <200004110032.RAA29933@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004110032.RAA29933@usr09.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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