I don't see where binders are more general.
That said, if you want to work on helping to implement this, great, I
think we can start with doing the easy tasks, and then do the hard ones later.
Hans
Wanderer writes:
> Linus Torvalds wrote:
>
> > In article <m10vnlI-003VuJC@reiser>, root <reiser@ceic.com> wrote:
> > >
> > >I convinced him that directories can do this, and do it cleaner than
> > >that MS crud they use as an FS model. The directories need a few
> > >features added though.
> > >
> > >First, they need to be able to have a file that when you read them they
> > >resolve to. That is, inside the directory there is one file that when
> > >you open (dirname) you get a file descriptor pointing to
> > >dirname/default. Now please note that dirname/default can be a symlink,
> > >a hard link (presumably to a file within the same directory), it can be
> > >all sorts of things. It can also be called something like "....", or
> > >even "". I have to think some about which I like.
> >
> > Note that the Linux VFS layer was pretty much _designed_ with something
> > like this in mind. From very early on, I decided that the VFS layer
> > should not make too much of a distinction between a directory and a
> > regular file: both have "lookup" properties, and both have "read"
> > properties.
> >
> > Some of that has been corrupted over time, and some of it was never done
> > because nobody actually used it - so there's a few places where the VFS
> > layer does things like "if (!S_ISDIR(d_inode->i_imode))" etc and thus
> > "knows" about the difference between a directory and a regular file, but
> > that was never really meant to be a design goal, and I'd be happy to try
> > to clean it up.
> >
> > So basically it all should be doable today: if a low-level filesystem
> > wants to export directories both as regular files and as pathname
> > components, it can be done. The low-level FS can look at the
> > O_DIRECTORY flag to know whether somebody wants to read the thing as a
> > directory or not (ie "readdir()" obviously opens the directory, while
> > normal operations open the default file), and it should all work pretty
> > much today.
> >
> > It's going to confuse a lot of UNIX applications, but at the same time a
> > reasonable number of them won't ever really have to know.
> >
> > >Next files need to be able to inherit stat data, so that a file can
> > >share its modification time with its parent directory, so that modifying
> > >the file changes the mod time on the directory.
> >
> > I don't think that is true. I think the directory and the file should be
> > considered separate, it's just that "lookup()" can find one or the other
> > depending on use..
> >
> > So I think it should be considered a _naming_ issue, and not much else.
> >
> > >Finally, you need a new file type flag indicating that it is both a file
> > >and a directory.
> >
> > Not necessarily. Just open it with O_DIRECTORY (or with a slash at the
> > end) and it gets opened as a directory, otherwise it gets opened as the
> > file. Works today, and is the most transparent option anyway.
> >
> > Things like "tar" etc probably need to be taught about how to see
> > distinctions like that, and we may want to have other ways of accessing
> > the information, but I don't think we _have_ to have them.
> >
> > Linus
>
> Seems to me that this proposal is a simplified, and less capable form, of my
> previous proposal
> for a "binder" extension. A binder being a file that contains an internal
> directory of addressable
> files (or objects). To reduce overhead, I proposed using two bits of file
> flags to indicate that an
> entry has not yet been checked as a potential binder; is definitely not a
> binder so VFS can avoid
> extra processing; and an entry is definitely a binder so VFS needs some
> recursive processing
> (originally I had two variations of this).
>
> All system calls that operate on directories see a binder as a directory. All
> system calls that
> operate on files see a binder as a file. (I have a preliminary map of calls
> around here and only
> a minimum number of calls are ambiguous.) Any of the rare special
> applications that need to
> be aware of binder structure would have a user space library of special calls
> (that are already
> fully present in VFS). No existing applications are impacted at all -
> including tar which
> could easily use the binder as a file or its contents. (Content use by tar
> would lose some
> type information - see below).
>
> Instead of a 'default' entry, I proposed the use of a file name map that
> permitted all accesses
> within a binder to be re-directed. This was intended to allow applications to
> be placed in a
> binder along with its resources.
>
> The original message mentions Mac Forks. Mac files have a resource and a data
> fork. Think of
> a binder as a Mac style file with any number of forks! Each fork is named by
> its internal directory
> entry name. And we allow nested binders in binders just like any file system.
>
> I originally suggested a two phased implementation with the first phase using
> actual fs
> directories to emulate a complete binder implementation. As I thought about
> it further, this
> is really not satisfactory as one goal was to have complete (mime-like) type
> and format
> information for each entry (object) in a binder. To store this additional
> file stat information
> nearly mandates that binders be implemented as VFS files with meta-object
> handling added
> for binders. Applications that need access to, or to manipulate, extended
> type information
> would need to use the user space library.
>
> One approach, that I haven't studied in detail, would be to have a special
> super block device
> to handle binders. All opened binders would be associated with this special
> super block
> so that the 'device' routines are handled properly.
>
-
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/