From owner-freebsd-arch Mon Apr 10 17:33:24 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 019B837B64B for ; Mon, 10 Apr 2000 17:33:21 -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 CAA05143 for ; Tue, 11 Apr 2000 02:33:20 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA06525 for freebsd-arch@freebsd.org; Tue, 11 Apr 2000 02:33:17 +0200 (CEST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 85B4237B806 for ; Mon, 10 Apr 2000 17:33:05 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id RAA19902; Mon, 10 Apr 2000 17:32:20 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAAkca4XM; Mon Apr 10 17:32:15 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA29933; Mon, 10 Apr 2000 17:32:50 -0700 (MST) From: Terry Lambert Message-Id: <200004110032.RAA29933@usr09.primenet.com> Subject: Re: RFC: kqueue API and rough code To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Tue, 11 Apr 2000 00:32:50 +0000 (GMT) Cc: dillon@apollo.backplane.com (Matthew Dillon), jlemon@flugsvamp.com (Jonathan Lemon), archie@whistle.com (Archie Cobbs), freebsd-arch@freebsd.org In-Reply-To: <20000407001929.N80578@prism.flugsvamp.com> from "Jonathan Lemon" at Apr 07, 2000 12:19:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My vision in this scenario is that each library will create it's own > kqueue, and register the events that it is interested in within that > kqueue. This way there is no conflict between events registered by > a library, and those registered by the main program. (recall that the > uniqifier for an event within a kqueue is (ident/filter). I would like to recommend that this interface be made into a bidirectional interface. 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. One specific use I envision for this would be to allow the creation of a /dev/lmi device for doing link management for a dial-on-demand border router (8-)). 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). This is a somewhat specific example, but you get the idea: it could be a more general means of communicating between the kernel and a user space policy daemon. Another example would be a "session manager". I know that there is some current work ongoing on a FreeBSD SMBFS. It would make a lot of sense to have a session manager that lived in user space (e.g. in an X session or on the console, or with a local credential cache -- this last would be only useful for pre-need authentication caching) that could pop up a kernel request to a user for credential information that would then be used by the kernel in order to establish a per user authentication instance (instead of a kludgy system-wide single credential). One could envision this being more generally useful, for things like a cryptographic file system that wants a credential in order to encrypt/decrypt FS data, or allowing per directory or per file access authentication requirements to be imposed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message