[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

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.