abstract file (support multi-part)

[Clayton Weaver <cgweav _at_ eskimo.com>]

Thinking about Linus' message, my first intuition is that the
sane approach is to support multi-part files natively in VFS as
the default model of a file, and just drop all parts that are not
applicable when accessing traditional unix files.

Linus says we should support multi-part files because filesystems
for which they are the native model of a file already exist and
aren't going to go away merely because they are messy compared to
"simple" unix files.

But traditional unix files are only simple from the point of view of
user-space software. The single byte-stream is already a kernel fiction
even in current filesystems that do not support multi-part files. The
directory entry for a traditional file contains a variety of other
information besides the inode number and the offset to and extent of
the data blocks that represent the file's data.

Multi-part files are like directories, but they don't have to actually be
directories in the VFS. They need the same structure but different
capabilities handling.

Note: a "thumbnail" for an image or a "sticky note" is a user-space
concept. For the kernel, it's just a nested multi-part file that is an
attachment to the multi-part file that it is attached to. It can inherit
the capability_constraints/acl parts from the parent file, but it's
basename part, inode, and block offset/extent of its data are its own.

A VFS backend would handle filesystem-specific semantics for what the
parts can be exactly, when they are required, etc, for legacy multi-part
filesystems.

So, in sum, "everything is a directory"?

Regards,

Clayton Weaver
<mailto:cgweav _at_ 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 _at_ vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/