Date: Tue, 11 Apr 2000 00:32:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jlemon@flugsvamp.com (Jonathan Lemon) Cc: dillon@apollo.backplane.com (Matthew Dillon), jlemon@flugsvamp.com (Jonathan Lemon), archie@whistle.com (Archie Cobbs), freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <200004110032.RAA29933@usr09.primenet.com> In-Reply-To: <20000407001929.N80578@prism.flugsvamp.com> from "Jonathan Lemon" at Apr 07, 2000 12:19:29 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004110032.RAA29933>