lkml.org 
[lkml]   [1999]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: (reiserfs) Re: Summary of how linux can best avoid the need for streams
    Albert D. Cahalan writes:
    > Richard Gooch writes:
    > > Hans Reiser writes:
    > >> Richard Gooch writes:
    > >>> Hans Reiser writes:
    > >>>> Richard Gooch writes:
    > >>>>> Hans Reiser writes:
    > >>>>>>
    > >>>>>> I am not saying put an FS into a file, I am saying make the filesystem
    > >>>>>> effective enough that nobody needs to create things like structured
    > >>>>>> storage. Given that as a goal, what is needed?
    > >>>>>
    > >>>>> I don't even concede this goal. In some cases "structured storage"
    > >>>>> inside a file is quite reasonable and efficient.
    >
    > You have a 1.5 GB file composed of 3 evenly sized parts and a
    > header. The middle part grows by one byte. Eh, what now?

    I've never advocated that you should put such data into a single
    file. I've said that before and I'll say it again. The example you
    raise is just one in a large space.

    All I am saying is that for some kinds of data (such as a single,
    large growing component and any number of small maybe growing
    components), storing it in a special file is fine. It's been done and
    it works well. I have already said that this case does not apply in
    general.

    > > I advocate putting albods/data forks/streams/what-have-you into
    > > separate files in a directory, and making no changes to the kernel or
    > > libc. That means the default behaviour of the kernel, libc and system
    > > utilities is that a directory-based albod is just another directory.
    >
    > In other words, scratch this whole idea.

    Yes.

    > Suffer your choice of inefficiency or user-hostility.

    No, I didn't suggest that. Again, I favour optional extensions to new
    and existing tools, so that you can view albods as either atomic or as
    conventional directories. Make the default behaviour configurable on a
    per-user basis (~/.resource-file) and allow that default to be
    overridden on a per-execution basis.

    > > Other (optional) behaviour can be added on top of this.
    >
    > This can not be. If you really think that random user-space software
    > developers will agree on a way to use directories as documents...

    That doesn't matter. If GUI developers can't agree to use a common
    library, it does not follow that the functionality should be pushed
    into the kernel/libc.

    > It isn't enough to have a few GUI apps. Users will be confused by
    > the inconsistent treatment.

    No they won't. Each user can edit ~/.albodrc. Generic luser has:
    CMD_LINE_MODE=cooked
    GUI_MODE=cooked

    but power users are free to do:
    CMD_LINE_MODE=raw
    GUI_MODE=cooked

    Everybody gets all 4 possibilities. Or you can just make it a single
    option that applies to the command-line and to GUIs. Doesn't matter.

    The point is everybody can be catered to with this scheme. Hacking the
    kernel/libc *prevents* a *legitimate* mode of operation. That is
    simply unacceptable.

    > >>> No, I didn't say that. What I'm saying is that the most common user
    > >>> who wants to see albods as atomic is sitting behind a GUI.
    >
    > When I write code, I want a way to get at the inside.
    > When I do other things, I don't want to bother with such details.

    I don't work the way you do. I want raw mode at the command
    line. Always. I should not be prevented from doing that.

    > >>> Command-line users who want to see albods as atomic can use some
    > >>> special tools, or perhaps switches to existing tools.
    >
    > Command-line users who want to see the parts can use special tools.
    > $ albod -x 80A8C452 ~/foo.doc > a.png

    NO! I want *all* my existing tools to be unaffected. I don't want the
    semantics changed. But I'm quite happy for another user on the machine
    to use cooked mode.

    > >> I don't understand you, except that I think you know how you have
    > >> seen it done, and think that the way it has been done must be the
    > >> right way.
    > >
    > > You're being offensive.
    >
    > I'd say you are afraid of change. When the topic isn't devfs... :-/

    I'm afraid of having different semantics shoved down my throat.
    Actually, I'm not afraid, I'll just rip such nastiness out of my
    system, and if necessary maintain and distribute a kernel patch if
    that's what it takes.

    The difference between devfs and kernel space albods is that with
    devfs I provide choice. There are a range of operating modes that
    users are free to use (and I note that some devfs detractors are
    effectively trying to prevent me (i.e. any user who just wants to
    download a kernel from Linus and not patch it) from having the full
    range of choice).

    With kernel space albods, I don't get the choice of having all my
    tools work in raw mode. This is why I'm fundamentally opposed to
    them. The key point is that I support the availability of new
    semantics but I oppose the restriction of existing ones.

    > > If you stuff around with the kernel/libc, you make it hard/impossible
    > > for people to see the raw components (real files in real directories).
    > > I can't stress enough how wrong that would be.
    >
    > What use are the raw components? They won't be in any file format
    > that you would normally use. They may be headerless raw image data,
    > binary markup language, binary data structures, etc.

    That's not true. They may have gif files, for example. And the headers
    are somewhere in the albod directory.

    > Since you need a special tool to create plain text anyway, you
    > might as well have that tool use the sub-file extraction API.

    I have a range of tools I can use to create text. The simplest is
    <cat>. I don't need a special API to write text.

    > >>> Sometimes, you really want to get in at the raw interface and play
    > >>> with things.
    >
    > This isn't VxWorks. You can't do system calls on the command line,
    > and I don't see much demand for that feature either.

    ??? I'm talking about system utilities, ls, sed, awk, perl, tr plus a
    whole bunch of my own custom utilities.

    Regards,

    Richard....

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

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.027 / U:60.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site