lkml.org 
[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: I discussed reading directories as files with jra, Stallman, and loic
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans