A common VFS and a Common conf-system (Was: namespacing)

[Avery Pennarun]

On Tue, Mar 01, 2005 at 07:14:28PM -0500, Sean Middleditch wrote:

> The POSIX API is expected to work in terms of certain syscalls, while a
> VFS implementation of a particular POSIX API call will often make many
> syscalls, none of which are the one being emulated - that alone makes it
> pretty darn hard to do things right, and is what most of the complexity in
> FUSE attempts to address.

You make this sound hard, but it's only as hard as you want to make it; for
example, the guys who invented NFS didn't want to make it hard, so things
like O_EXCL create, caching, locking, and unlink-while-file-is-open don't
really work right.  If you leave off the details, you can make something
that's "mostly posix" and does most of what people want.  (Almost no apps or
people use any of those features, which is why they can survive with NFS.)

And then, if you're speaking a protocol that *can* be posix-compliant, you
can make it so.  That's well worth it, because those fancy posix
restrictions are all there for very good reasons.

> In all honesty, though, WHY would you want a POSIX API?  What possible
> advantage would someone hope to get from emulating the POSIX API on top
> of the VFS?  The only thing I can think of is backwards compatibility
> with legacy apps, but I'm not sure that's really all that worth the
> problems that would arise.

Legacy apps like gcc, make, vim, emacs, bash, find, mc, mysql, apache,
samba, and netatalk?  I think it's worth a bit of effort to make those work
with, say, SMB or WebDAV filesystems.  Ask Microsoft how important backwards
compatibility has been to their success.

On the other hand, write the VFS first, and just make sure it *can* do
everything posix can do.  Don't go all crazy and restrict it so that every
possible VFS backend *does* work like posix.  The people like me who want
the backwards compatibility will make sure it happens eventually, as long as
it's possible to do so.

Have fun,

Avery