Fwd: Re: A common VFS and a Common conf-system [Part II]
kevin.krammer at gmx.at
Wed Mar 9 13:27:38 EET 2005
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
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
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
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.
More information about the xdg