On Fri, Jan 21, 2005 at 10:27:33AM +0100, Ivan Popov wrote: > If you mean a more general "cache bookkeeping library", then possibly yes, > but still you'll get differences depending on how FSs and OSs distribute > functionality between kernel and user space in a filesystem client.
i believe stephen is referring to storing NT authentication "session keys", which are required to perform DCE/RPC signing and sealing, that sort of thing. i believe stephen envisages a situation where a user logs in with a program (or uses a modified version of a pam module) that performs NT-style authentication, and then the program or pam module communicates the response to the kernel, which caches it "safely" somehow. then, should other programs or kernel modules (such as a filesystem module, or a user-space service, or smbclient, or REGEDT32.EXE running under Wine) require access to those cached credentials, they may do so immediately and via a well-defined interface. this may get rid of the need, for example, for smbmount to use an ioctl to communicate with smbfs.ko which passes over the SMB username+password. that sort of thing. personally, i think the whole idea of having complex filesystem clients inside the kernel is utterly insane, and that userspace filesystems like fuse (not so hot), lufs (much better) where you write a userspace helper daemon is much better, and that application-level plugins for desktop systems like KDE (which even has a webdav filesystem plugin), and simple command-line tools like smbclient and ftp should be used instead. you _really_ want to port dce/rpc client-side code into the linux kernel??? and you've _really_ ported the AFS client-side code into the linux kernel?? *shriek*!!! :) the gnu/hurd has the right approach to this issue: the kernel "helps" you to "publish" a userspace service via well-known interfaces such that other programs may use your "service" as system calls. ironically (given the people on this list i think you'll appreciate this), in order to achieve this, the gnu/hurd team had to write _their own_ RPC system - including an IDL compiler - from the ground up and utilised Mach kernel message-passing as the transport. now, if you proposed that the linux kernel gained message-passing, or similar features to gnu/hurd to achieve the same effect, or you proposed improvements to the linux filesystem structures such that lufs and fuse don't end up locking large critical structures, i'd say "GREAT!" ... but instead, i'm going to say "good luck" :) l. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
