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

Sean Middleditch elanthis at awesomeplay.com
Tue Mar 8 23:04:33 EET 2005


On Wed, 2005-03-09 at 09:39 +1300, Perry Lorier wrote:
> > When FUSE equivalents are in BSD, Solaris, HP-UX, Cygwin, Irix, etc.,
> > *then* it's worth taking into consideration.  Until then, FUSE is
> > absolutely useless to D-VFS, unless we code some huge and massively
> > different version just for Linux, which is both insane and pointless.
> > 
> 
> If someone is very careful, you could implement a VFS using LD_PRELOAD, 
> which is a lot more portable.  Overriding the POSIX API's to call 

You can't really, though, because many functions which should map to a
single syscall would map to many syscalls in D-VFS.  That's pretty much
the prime reason why you have FUSE - to make sure syscalls behave
appropriately.  If you didn't need that, you FUSE could be done 100% in
userspace, since it really is just a POSIX-only version of D-VFS with
kernel assistance.

Or, even when a single syscall might still be involved, the actual
semantics are still different.  When you write() 10 bytes to a file, you
just write 10 bytes to a file.  When you write() 10 bytes to a VFS file,
that request as to be communicated to the daemon with some overhead
(namely, the operation, the length of bytes to be written, the file
handle, etc.).  Since that single call can be interrupted, you now have
a situation where the library needs to make more syscalls but the
application has no knowledge of this - only whether its part of the
request payload was written or not.  I can think of a few possible
solutions (which probably have holes) but they're all vastly ugly and
inefficient.

It's the kind of problem you might not notice 95% of the time, but that
other 5% is still very, very important.

> through to a daemon is at least doable.  The thing to be wary of is that 
> a lot of programs (eg, cp) assume a lot of structure in their filenames, 
> and will quite happily cull out "//"'s and suchlike in filenames. 
> Having filenames look /vfs/http/server/path/file.html seems to be the 
> best solution to this problem.  If the OS has capabilities such as FUSE 

Now we get back to that 'two namespaces' problem that 'gtg' was talking
about - you can't cut-n-paste a URI from your browser window, for
example.

Simply "fixing" cp and such might just be easier if you're going to go
so far as to integrate D-VFS (or something like it) at such a low level.
Which gets back to porting...

> (or hurd's file system translators or...) then it can be implemented 
> with kernel support.  If the OS has no such capabilities, then the 
> LD_PRELOAD method can be used instead.  GUI API's can rewrite the 
> "/vfs/protocol/" to and from "protocol://" when displaying it to the 
> user if URL looking URLs are a design requirement.
> 
> Getting this to work well is hard.  I managed to write one a few years 
> ago that worked with ftp for small values of work.  (you could vi 
> /ftp/ftp.example.com/pub/example.txt and it would work mostly).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>




More information about the xdg mailing list