First, the ability to mash a bunch of file streams into a single
disk file, ala MS's COM structured storage. This is clearly
something that can be done wholly in user space, and would
be usable only to albod/masg-aware applications. All other
code would see the albod/mash as a single binary disk file of
unknown flavor. This could be done simply, and it would impose
no overhead on programs or the system when it was not
used, both very attractive features.
Second, the ability to assign semantics and characteristics
to the albod itself and/or the files it contains. This is where
things get really murky. In order to make albods work in this
way, they need to be self-identifying, either through
meta-data or via a signature. Meta-data has the problem of
being easily lost, as others have mentioned, and signatures,
while allowing support on ancient FS's like FAT, have a
potential performance problem (if Linux or a file manager has
to scan all the files in a dir. looking for albods), plus the small
but non-zero chance of a false positive identification. Neither
problem is acceptable, IMO. Any change to Linux of this
nature has to be 100% bullet-proof (or at least closer than
this would be).
What level of functionality is truly desirable? My opinion is
that just the first one, the standalone file mash, gets us 95%
of the desirable utility (where utility is not identical to functionality),
and in a very favorable form (no impact on the rest of the
system, etc.). There could be changes made to some
commands, to explicitly address the contents of a mash,
but these could come later, and would be a separate effort.
If the Linux kernel developers want to tackle the general
idea of an inherent file identification scheme, I think that would
be a good thing in the long run, since I believe Linux would
benefit from that. But IMO that's a whole other effort that
should be taken up separately, and not brought in through
the back door, so to speak, with albods.
Lou
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/