> As for "breaking many ordinary filesystem operations", well that's I
> think a matter of opinion and will depend strongly on your point of
> view.  Certainly you don't want to have mkdir(), or link(), or maybe
> even unlink(), do anything useful in /procfs, for example.

Exactly.

Processes do not support filesystem operations, so any attempt to use a
filesystem interface to processes (or a process interface to a
filesystem, though nobody ever seems to consider that) will necessarily
be a poor fit.  This is more or less what I meant when I wrote

>> The filesystem simply is not a good fit to many abstractions.  Look
>> at all the things you can't do with procfs, for example: both things
>> you can do with processes but not procfs "files", and things you can
>> do with normal files that you can't do with procfs "files".

> You should forget about treating virtual filesystem interfaces
> exactly as files from the point of view of using all the command-line
> file manipulation tools on them and expecting something logical to
> happen.

Exactly.  They aren't files; why try to make them look like something
they're not?

> The point of using the filesystem paradigm is to provide a simple and
> common system-call interface through open(), close(), read(), and
> write().

Why is this good?

Why should that interface be preferred over any other?  For example,
why not instead make everything a socket?  An AF_FILE socket would give
you access to filesystem files, an AF_PROC socket would give you access
to processes, etc....  Or make everything a sysctl MIB.

>> It's an interesting paradigm, but as I indicated above, is has the
>> problem that it ends up twisting everything into the filesystem
>> mold.
> That's not a problem -- it's an opportunity!

That's a matter of opinion. :-)  (Actually, I think it's both.)

> The only scary thing about the "files are everything and everything's
> a file" paradigm is that naive people are prone to adding
> non-sensical features to such interfaces

Not nonsensical at all - from a filesystem point of view.  This is
touching on what I meant when I wrote of twisting things into the
filesystem mold.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B