Fwd: Re: A common VFS and a Common conf-system [Part II]

[Kevin Krammer]

On Wednesday 09 March 2005 03:58, gtg990h at mail.gatech.edu wrote:

> In Linux, anyway, there is ongoing work to deal with the metadata issue,
> because of Reiser4 (among other things). Say a year down the road, Linux
> has APIs for this. Will D-VFS be unable to use them? That's the real
> impetus for making D-VFS operate on top of the native filesystem. As the OS
> becomes more capable, D-VFS can shunt more work to it.

If D-VFS is anywhere similar to KIO its local file access "plugin" will surely 
use the native API, very likely adding code for things like metadata in 
filesystems that don't provide them and using the FS provided metadata 
whenever possible.

I am pretty sure a file:// "plugin" isn't going to open the partitions as 
files and then implementing the filesystem access in user space.

> The organization would go more like: D-VFS -> kernel -> FUSE. There is
> little to no abstraction loss between the kernel and FUSE, because the FUSE
> VFS *is* the kernel VFS. There need not be any loss between the kernel VFS
> and D-VFS, because D-VFS doesn't exist yet, and can be designed in a way
> such that this loss does not happen.

Wouldn't that mean you had to reimplement D-VFS for every kernel you want to 
run it on?

> THat's the whole point of allowing D-VFS to provide its own implementation
> if necessary. Besidies, its is not the desktop's job to make up for
> deficiencies or bugs in the OS.

True, but sometimes the OS cannot be altered by the parties involved in the 
desktop projects.
I am not sure all the vendors of the Unices our desktops run on will let the 
D-VFS developers have write access to their kernel repositories or include 
their patches.

Of course in an ideal world some standard body like POSIX would specify an 
appropriate remote access API and all OS developers would implement it the 
minute it is published, but my latest reality check says I still live in a 
non-ideal world. Bummer.

Cheers,
Kevin