Re: abstract file (support multi-part)

[Jesse Pollard <pollard _at_ cats-chateau.net>]

On Sat, 19 Aug 2000, Clayton Weaver wrote:
>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.

Ummm. sorry. The directory entry contains only:

              struct dirent
              {
                  long d_ino;                 /* inode number */
                  off_t d_off;                /* offset to this dirent */
                  unsigned short d_reclen;    /* length of this d_name */
                  char d_name [NAME_MAX+1];   /* file name (null-terminated) */
              }

Only enough to support directories. Even the kernel structure doesn't have
more (from linux/fs/readdir.c):

struct old_linux_dirent {
        unsigned long   d_ino;
        unsigned long   d_offset;
        unsigned short  d_namlen;
        char            d_name[1];
};                                                                                             

Everything else is in the inode. No "extent of the data blocks". The byte-
stream is implemented via runtime library. read/write transfers variable
length buffers.

>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.

And that bloats the VFS code, with something that will perform like a 
directory, look like a directory, and act like a directory, but not
"be a directory". (If it quacks like a duck, and ...:)

>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"?

That seems reasonable, but this thread isn't about being reasonable.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard _at_ cats-chateau.net

Any opinions expressed are solely my own.
-
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/