Re: file as a directory

[Peter Foldiak]

On Wed, 2004-12-15 at 04:47, David Masover wrote:
> Peter Foldiak wrote:
> | Also, a pseudofile (e.g. dirname/..../structure ?) could be used to
> | specify how the files should be glued together. A simple question is,
> | for instance, what separators to use between the components, and what
> | ordering to use when putting the component objects together. (This
> | pseudofile could also determine more complicated ways of composing
> | objects.)
> 
> If the filesystem does caching, I'd rather have a type of executable
> which, read normally, appears as a stream of its own standard output.
> You'd get the actual file as something like bar/.../source.

This sounds better and more general than my proposed ..../structure
file. So could you explain this in a bit more detail?
Would for instance the simplest (and default?) glueing code in your
bar/..../source file be

cat *

which just concatenates all the subcomponents in no particular order?


> This could be done with pipes and daemons, but it's not as easy to
> manage and seems impossible to do as efficiently (with built-in caching,
> etc.)

How would you do it?

> 
> | The component objects themselves could be full objects, so they
> | themselves could have sub-components.
> 
> Right.
> 
> Also, there should be an inverse. For instance, a file-as-directory type
> object should have a "contents" object, usually a normal directory, but
> which could conceivably be any type of object, including a code-ish
> object which implements a filesystem. Accessing foo/ would be the same
> as accessing foo/.../contents, only because "..." (or whatever we use
> for meta-files) is outside the actual directory namespace,
> foo/.../contents/... refers to the metas of object "contents", which are
> different than the metas of object "foo".
> 
> These two steps essentially create userspace "plugins", and do away with
> having to mount other kernel layers such as lufs (or whatever its
> current implementation is). It does have one important implication, though:
> 
> It's important that "metas" or "..." or whatever we've decided on should
> _not_ be mutable by a "userspace" plugin that I have described, nor
> should any meta-files created by kernel plugins. There would be other
> security implications, of course -- user should still not be able to
> create files that are owned by other users and setuid. I'm not sure
> where such checks should go, but we want mortal users to be able to add
> whatever plugins they want, while super-users can feel safe using the
> metas interface to manipulate user files.

Sounds really interesting.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/