[lkml]   [1999]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

> > 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.


> 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:

but power users are free to do:

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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.056 / U:1.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site