lkml.org 
[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: abstract file (support multi-part)
Date
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@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@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:37    [W:0.948 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site