Re: reiser4 plugins

[Hans Reiser <reiser@namesys.com>]

Martin Waitz wrote:

>hoi :)
>
>On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
>  
>
>>You could do filesystems in userspace too and just use the kernel's
>>block layer.
>>    
>>
>
>but you can't do that in an library, you have to use a filesystem
>server in order to get access control.
>But you can build a library that handles uniform access to
>files and directories.
>
>Don't get me wrong, I'm all for a uniform interface for files and
>metadata, but I don't think that it has to be in the kernel.
>Gnome and KDE already have their own userspace VFS, something
>like that should be used.
>
>One has to distinguish between the low-level filesystem and
>the storage system which is presented to the user.
>
>  
>
Yes, but to do what you advocate properly, the existing semantics
currently in the kernel should be moved out of it into user space.

I think the exokernel approach by Frans is a very interesting approach. 
I wish I had the experience with it necessary to know if it was
effective.  I do NOT take the position that name resolution should be in
the kernel.  I DO take the position that it should be either in the
kernel or out of the kernel, and should constitute one cohesive and
coherent body of code.  If someone talks Linus into trying the exokernel
approach, I will be happy to educate myself to where I have an opinion
on whether that works.  It is easy to see powerful advantages to the
exokernel approach: I wish I understood the security model for it, and I
wish I was sure that name resolution would not require too many context
switches as one fetches each storage component required by a name
resolution.

Masover's words about HURD earlier in this thread were very well said. 
Context switching is expensive, and I find it easier to be sure my code
will both perform well and be cohesive if it is all done in the kernel
by one body of code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/