Clayton Weaver wrote:
[...]
> That's my final opinion on this: it could be done, by writing a different
> VFS for each storage object model that doesn't fit the unix model,
[...]
> Maybe they lose a little bit of backing store locality, big deal,
> it's a good trade for only having one much simpler VFS in the kernel
> instead of a dozen of them, each with it's own quirks and bugs (imho, of
> course; feel free to write an alt-VFS for HFS or NFSv3 or NTFS or whatever
> if you have the time for it).
>
I believe you can support quite a lot of filesystems with a single
extension of VFS. Some variant of the file-as-directory concept,
or for full unix compatibility: a directory named
<filename>-otherstreams
or similiar.
The extra streams, ea's, or whatever can then be found as files in the
directory. File attributes that don't have names in the native fs
may get simple numerical names. The fs driver is responsible for not
creating anything illegal, (i.e. hpfs ea's is max 64k.)
This scheme won't fit everything perfectly, so how do we support
an app ported from mac, os/2, or NT? That part can be done
with userspace libraries. A "ntfs library" can convert
open("filename:stream") to open("filename/stream") or
open("filename-otherstreams/stream") Or the people doing
the port might want to port to linux-style streams for this
simple case.
A "hpfs library" can convert the EA-calls in
os/2-ported programs into file operations in the
correct directory. And so on.
This apporach makes for fewer kernel changes, with most
of the job in fs-specific libraries.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST