Messages in this thread |  | | Date | Fri, 25 Aug 2000 13:19:56 +0200 | From | Helge Hafting <> | Subject | Re: [OT] Re: abstract file (support multi-part) |
| |
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/
|  |