Messages in this thread |  | | From | Jesse Pollard <> | Subject | Re: abstract file (support multi-part) | Date | Sun, 20 Aug 2000 12:05:10 -0500 |
| |
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/
|  |