A virtual filesystem standard
vincent at ricardis.tudelft.nl
Thu Sep 18 12:12:35 EEST 2003
On Thursday 18 September 2003 08:51, Alexander Larsson wrote:
> On Thu, 2003-09-18 at 02:15, Vincent Wagelaar wrote:
> > On Tuesday 09 September 2003 15:50, George Staikos wrote:
> > > On Tuesday 09 September 2003 03:29, Alexander Larsson wrote:
> > > > On Mon, 2003-09-08 at 16:53, Owen Taylor wrote:
> > > > > What would be of extrodinary value, I think, would be a writeup of
> > > > >
> > > > > - What works well with KIO
> > > > > - What doesn't work / requires hacks
> > > > > - How it could have been done better
> > > > >
> > > > > I can try to get someone familiar with gnome-vfs (maybe Alex
> > > > > Larsson) to do the same for that.
> > > >
> > > > Yes, this would be interesting. I'll try to find time to write it up.
> > >
> > > Hopefully Waldo and/or David can help and we can do the same. I
> > > think it's quite important to plan this out properly before diving in
> > > head-first.
> > Maybe another idea...
> > For Linux there exist atm two implementations of a virtual filesystem
> > kernel module:
> > Lufs (http://lufs.sourceforge.net/lufs/) and
> > Fuse (http://sourceforge.net/projects/avf).
> > Wouldn't this be an idea (at least for Linux, don't know if other os's
> > have something similar).
> > Instead of using smb:// thumbnails:// ftp://host you would simply map it
> > to: $HOME/vfs/smb and $HOME/vfs/thumbnails $HOME/vfs/ftp/host etc. Or
> > $HOME/ Desktop. The biggest advantage is that all programs work would
> > work out of the box, instead of requiring yet another library.
> There are all sorts of problems with this. Permission issues (need root
> to mount), kernel stability issues, no standard async i/o API, not
> portable to all unixes, no good way to handle authentication, etc.
Smbmount is also suid root (at least on debian). why would we need async io,
the current vfs implementations aren't performance monsters either. fuse has
limited access to the mounts to the user that has actually mounted it.
i would guess that stability would be greater because most code is outside the
> Personally i think kernel handling for this is just a bad idea. Fuse is
> not a kernel thing. Its a LD_PRELOAD thing. I'm even more strongly
> agains that, since it makes all apps slower (talk to uli about
> LD_PRELOAD sometime) and breaks the semantics of real system calls.
Huh, please reread the website. there are 2 projects. one is fuse (kernel
module) and another, avf, that is using the coda filesystem (and an optional
ld_preload version for e.g. solaris).
More information about the xdg