Messages in this thread | | | Subject | Re: file as a directory | From | Peter Foldiak <> | Date | 15 Dec 2004 09:27:34 +0000 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |