Re: VFS integration with kernel mounts

[Jerry Haltom <wasabi larvalstage net>]

> But the user can't mount a kernel mount. Only root can do that. In fact,
> this is one of the primary reasons we're creating a user space vfs. So
> that any user can create a cifs mount on any platform without being
> root.

I thought it was because POSIX doesn't provide an abstraction clean
enough for application developers to write robust async code with good
user interfaces. And to an extent, I completely agree. I think it would
be unwise to not recognize that existing kernel modules actually do
provide the best implementation of a given file system currently. FAT
being a prime example. We don't have a user space implementation of it,
and probably will not ever, so we need to solve this case for it. And to
an extent, with ideas like pmount and... whatever it's replaced with ,
we have.

> Sure, paths have problems. But your made up uuid uri has problems too.
> Like aliasing, or the risk of non-unique uuids and other fragility
> problems.

What do you mean by aliasing? I don't understand the reference. As to
non-unique uuids, I'm not sure how to respond to that. uuids should be
unique. Hence the u. If they're not, somebody should fix it. I think
we've accomplished this pretty well already for USB block devices and
other file systems.

> > > Not sure what you mean. gvfs backends can support mount on demand if
> > > that is what you want. But fuse mounts are not really different than any
> > > other kind of mounted filesystem, what special needs do you have?
> > 
> > The only need I'm talking about is hiding the actual POSIX location of
> > the mount from the user. If the user is talking about flickerfs, he
> > should be able to refer to it as flickerfs://, and not have to refer to
> > it as file:///mnt/myflicker/.
> 
> In general the user shouldn't have to type uris at all. If a flickerfs
> is mounted it should be there in the ui, clickable. And anyway, we won't
> mount the flickerfs system like that. It will be a user-level mount that
> is accessed through gvfs and addressed using URIs.

Agreed with your primary point. The term user here isn't appropriate.
Are we planning to redo flickerfs as a GVFS file system module? Would it
not make more sense to use the existing FUSE code?

> The g_file_get_path() is meant to return the fuse path in case of a
> non-native GFile when there is fuse support. This works exactly like you
> say above. It is possible to make it point to other locations than
> ~/.mounts/ if we make uri schemes that just alias part of the unix tree,
> but as i said in my reply to davidz, I think that is very risky to do.

I would really like to get a better idea of your objections. What about
this is fragile?