A common VFS and a Common conf-system (Was: namespacing)
elanthis at awesomeplay.com
Wed Mar 2 02:49:28 EET 2005
On Tue, 2005-03-01 at 19:36 -0500, Avery Pennarun wrote:
>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
And it shows in many, many places - there is lots of software that just
doesn't work right on NFS because they expect defined behavior that
works in an incorrect manner.
And, for D-VFS, it's moot, since we're not using POSIX - not worth
arguing about, really. :)
>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.
But, most interesting protocols aren't. Accessing NFS isn't something
D-VFS will ever do, since NFS shares will just be mounted normally.
We're more interested in WebDAV, FTP, SFTP/SCP, etc.
>> 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
Why would we care about those? Those aren't the target applications and
their needs are 100% irrelevant to our design.
>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.
I doubt it will do everything POSIX can, at least not anywhere near as
efficiently or easily in certain cases. It's not intended to. It's
made to read and save documents, browse folders, and do basic file
management. If you want more, don't use Desktop VFS - use NFS or FUSE
or something else. D-VFS is in no way meant to deprecate FUSE or other
system-oriented network VFS systems. D-VFS's just meant to provide an
alternative that makes far more sense for a certain target set of
applications (desktop apps and graphical file managers).
>xdg mailing list
>xdg at lists.freedesktop.org
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg