Re: reiser4 plugins

[David Masover]

Hubert Chan wrote:
> On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro <ross.biro@xxxxxxxxx> said:
>
>
> > I'm confused.  Can someone on one of these lists enlighten me?
>
>
> > How is directories as files logically any different than putting all
> > data into .data files and making all files directories (yes you would
> > need some sort of special handling for files that were really called
> > .data).  Then it's just a matter of deciding what happens when you
> > call open and stat on one of these files?
>
>
> Logically, I don't think there is a difference. A filesystem that
> doesn't support file-as-dir could implement the same functionality that
> way. [1]  In fact, that's essentially what MacOS X/NeXTSTEP does with its
> bundle format -- it's just a regular directory with regular files
> inside.

I, personally, would hate it if everything in my /bin suddenly became a 
directory, mainly because everything would stop working.  Is that the 
kind of thing you're suggesting?

I'm a little confused about the .data idea, I guess.

> > But we could have a whole new set of system calls that treat things as
> > magic, and if files as directories is as cool as many people think,
> > apps will start using the new api.  If not, they won't and the new api
> > can be deprecated.
>
>
> File-as-dir doesn't require new system calls (that I know of), which is
> the whole point of the idea.  Existing programs can edit the strange new
> attributes without being modified.

That is indeed the point, but scroll down.

> The main thing blocking file-as-dir is that there are some
> locking(IIRC?) issues.  And, of course, some people wouldn't want it to
> be merged into the mainline kernel.  (Of course, the latter doesn't
> prevent Namesys from maintaining their own patches for people to play
> around with.)

What's the locking issue?  I think that was more about transactions...

[...]
> People like Horst (and probably others, who are less vocal), I think,
> don't think that it's even worth trying it out because they don't see
> any major advantages.  Or at least they think that the potential
> negatives outweigh the potential positives.  I respect that they have
> different opinions, but I of course disagree and attempt to convince
> them otherwise.

Did the /meta (metafs) idea get killed while I was out?  Using that 
approach, your potential negatives are that apps which crawl the entire 
FS tree, starting at /, with hardcoded apps for /proc and /sys, are now 
broken -- but then, /sys already broke them once, so I don't 
particularly care if we break them again.

Potential positives?  I think even just because we like the idea is 
enough, because it doesn't break anything and doesn't really affect 
anyone who doesn't use it.

Maybe there are coding standards, but I think others are working that 
out now.
-
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/