Re: reiser4 plugins

From: David Masover (ninja_at_slaphack.com)
Date: 07/01/05

  • Next message: Hans Reiser: "Re: reiser4 plugins" 
    Date:	Fri, 01 Jul 2005 03:06:19 -0500
To: Hubert Chan <hubert@uhoreg.ca>

    Hubert Chan wrote:
    > On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro <ross.biro@gmail.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Hans Reiser: "Re: reiser4 plugins"