[]
> If so, then you open bar using the native API call ZwOpenFile. - The
[]
This ^^^^^^^^^^ is
the basic problem with any kind of multi-part storage object support
in kernel space. Because different multi-part storage objects implemented
by different native filesystems have different allowed and/or required
components besides the actual data, we need different open/read/write/
link/unlink/rename/fcntl/stat/close/et_al calls for each different set of
components (where more than one part of a multi-part file gets operated
on with a single system call).
For every new native multi-part object filesystem or even new version,
the specification of these multi-part objects is subject to change,
requiring for each such change a new set of functions that knows the
nature of the components of a particular kind of multi-part storage
object. Allowing such proliferation of required support functions at the
whim of vendors of other operating systems and the otherwise unenlightened
is bogus design at it's worst, imho.
When VFS only supports a single model, where everything that looks like a
file is a single data channel file, and any association between files
beyond what unix already provides is a user space application or support
library concern, then the proliferation of multi-part storage object
implementations at the demand of applications can take whatever shape it
wants, because it is not a kernel problem. It's merely up to the
application to be sure it has support coded someplace for it's "meta
storage objects" that cluster multiple discrete unix filesystem objects
together as parts of a user-defined multi-part abstract storage object.
With single data channel files, Linux only needs one set of system calls
in VFS. With multi-part files, we need one set of system calls
in VFS for every different kind of multi-part storage object model.
We can virtualize the "multi-" instead of single partness of it,
but that doesn't solve the "which parts are we using with this particular
filesystem" issues. The backend only does part of the job, VFS still needs
to know what to ask for. When we more-or-less need a different VFS for
each multi-part storage object filesystem type, we effectively throw
away what made VFS advantageous in the first place. We would be coding a
backend storage object model dependency into VFS.
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,
but it seems silly for the kernel to have to deal with all of these
different storage object models itself. Since when do applications
tell an operating system what kind of filesystem model it must have?
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).
Regards,
Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers
-
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