system and desktop VFS merged

[Diego Calleja]

El Wed, 30 Mar 2005 18:34:32 -0500,
Sean Middleditch <elanthis at awemud.net> escribió:



> Says who?  I say that's absolutely wrong.  The only thing that belongs 
> in the kernel is stuff that requires the kernel.  You need the kernel to 
> do block access.  You need the kernel to directly push bits around on 
> the block device securely.
>
> You don't need the kernel to access CIFS.  You don't need the kernel to 
> access WebDAV.  You need the kernel to do the networking, but that's 
> it.  There are many WebDAV implementations that work 100% absolutely 
> perfectly in userspace.  They don't need the kernel.

Yes, VFS don't accesses the hardware directly so VFS doesn't belong to the
kernel, in fact not even the block layer or the networking stack or the tty layer
or filesystem implementations accesses directly hardware and don't belong to the
kernel. 

However we live in a real world where real people (linux, BSD, solaris, NT, darwin) don't
uses pure microkernels and puts VFS in the kernel. So kernel VFS is the real VFS
layer, and it's the one who 100% of the apps use today. D-VFS aims to create a
"secondary" VFS which won't be visible to users of the main one, and which requires
modifying 100% of the apps if users of those apps wants to use files from a D-VFS
filesystem.

The right way of implemeting things is to implement it behind all apps. BTW: if you 
don't like FUSE and want a 100% userspace alternative, the following place to ask
for such functionality are the libc guys. Creating a secondary VFS which requires
modifications in _every_ app is not exactly the right way of doing things(Hint: libc guys
will say "no")


> craploads of code into the kernel - the absolute last place you want to 
> add more code - is at its very core a bad idea.  If you can possibly 
> implement something in userspace, then that's where it should be done.

FUSE in fact its about getting code _out_ (FAT, HFS, NFS, UFS, weird filesystems like
beosfs, etc) of the kernel. FUSE is not a functionality itself - its code used to build more
userspace functionality, and that is _good_. FUSE is in fact very near of being accepted in
the mainstream linux kernel (it has been in -mm for ages, and as far as I remember from
the lists it would have submitted already but some FS guy asked for time for a last
review ) - and they know better than you and me what are they doing.

Dragonfly is also aiming for something even better which other BSDs may use. Mac os
x has something similar, ditto for NT. The list of "relevant OS which don't have a
FUSE-like alternative" is not big. Not only it's a better design, people seems to be
going that way.


> Putting parts of D-VFS into the kernel buys you very, very little.  It 
> can help provide compatibility to old applications.  It's hard to 

"old??

So, apps who won't implement D-VFS are suddenly "old" and are "different"?
Can someone explain me why apache or GCC wouldn't need files from a D-VFS
filesystem, and who is going to implement and ship all the neccesary
patches when that happens, and deal with thousand of project leaders to request
that feature? (That's far more painful that upgrading your kernel and running one
application BTW)

New apps who use open() (in its several forms and in different languages) will not see
D-VFS files and will have to implement its handling separately. I won't be able to copy
a path from nautilus to cat or cp it in the console. It's not about "compatibility with
old apps". It's about a broken design. The fact that gnome-vfs and kioslaves have 
already been doing it wrong for ages don't justifies anything.


Hell, D-VFS doesn't even exists. FUSE is there, is almost merged, it is real code,
it's being used in real world scenaries, it works, its design doesn't break the the
filesystem namespace in two, it's how the rest of the world is doing it and its far more
clean than D-VFS, and it doesnt need to modify the 69438153 apps that D-VFS requires
to modify if the user of the apps suddenly want to retrieve a file from a D-VFS
filesystem.

	Diego