Messages in this thread | | | Date | Tue, 14 Dec 2004 21:28:06 -0800 | From | Hans Reiser <> | Subject | Re: file as a directory |
| |
David Masover wrote:
> Peter Foldiak wrote: > | On Tue, 2004-12-14 at 17:24, Hans Reiser wrote: > | > |>Peter, I think you are right, though it might be useful to have the > |>default be dirname/..../glued and to allow users to link > |>dirname/..../filebody to > |>dirname/..../something_else_if_they_want_it_to_not_be_glued, and to have > |>dirname/..../filebody or whatever it is linked to be what they get if > |>they read the directory as a file. > | > | > | Yes. I assume you mean that dirname in itself should always be > | interpreted as dirname/..../glued, which by default would be a linked to > | dirname/..../filebody, the latter being the file content, right? > > I think he means the other way. > cat foo > is the same as > cat foo/.../filebody > where "filebody" is some sort of link to (maybe) foo/.../glued. > > Understand that you want to allow "normal" files which are not "glued" > anything, but also "glued" files which are composed of sub-files. > > | 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.
Interesting....
> > 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.)
Explain the value of caching executable output more please.
> > | 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".
Are you sure that having more than one "...." is needed? Hmmm, interesting, must think about it.
> > 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).
I don't follow this point above.
> 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. > > I think the issues with directory-as-a-file were the same problems you > get when you allow hardlinked directories -- that you'd eventually have > to ditch reference counting for a garbage collector, which is hellishly > impractical. I don't have a solution to that, other than dropping > hardlinks entirely.
This issue is overblown. Other fields have solved this problem.
> > Hmm. Why do we need hardlinks? I forget.
- 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/
| |