[ On Sunday, March 26, 2000 at 02:11:25 (-0500), der Mouse wrote: ]
> Subject: Re: sysctl(2) and/or /kern for system variable manipulation
>
> But them excepted, I don't see why each object type shouldn't have a
> namespace suited to its nature.  The file paradigm is remarkably
> robust, but that's largely because of the unstructured ioctl() escape
> hatch, secondarily because people accept pseudo-filesystems that
> severely break many ordinary filesystem operations.

The ioctl() "escape hatch" as you call it is a kludge, and it always has
been, just as its designers have claimed pretty well from day one.
However it's not a necessary kludge, even today.  It's just as easy to
design a device driver that has a separate control channel (which uses
human-understandable control codes and responses if you're so inclined)
and now that we're no longer restricted to just 255 minor numbers per
device there are few objections against doing this other than "that's
not how we did it in the past".  The most recent device driver I wrote
supported only open(), close(), and ioctl() but it should have used
read() and write() instead of ioctl() -- I was just lazy and did it the
way I had always done these sorts of things.

Fcntl() is a different story and it won't go away easily or quietly.

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.

>  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".  (Simple examples: there's
> no procfs analog to fork() - the closest would be cp, and that's not a
> good fit - nor is there a process analog to mkdir().)

I think you've taken that metaphor far too far.  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.  The point of using the
filesystem paradigm is to provide a simple and common system-call
interface through open(), close(), read(), and write().  The fact that
command-line tools such as `ls', `chmod', etc. might work in some
circumstances is only a side benefit.  In the Unix process model you
can't force another process to fork no matter how you interface to the
kernel to control processes -- only the process itself can request this
action because it only makes sense to do from a planned point in the
process.  But if this did make sense to do it would be as simple as
implementing a "fork" command for the /proc/*/ctl interface where the
number you might read back from the channel after issuing the command
would be the new child's process-id perhaps.

However you can get rid of some process related kernel interfaces if you
use procfs exclusively, such as ptrace() and kill() [and of course you'd
turn these into library calls for backward compatability].

If you have other examples where namespaces (hierarchical or otherwise)
are required to refer to system objects but which you think are
extremely unnatural to migrate to a filesystem namespace I'm eager to
hear about them.

> 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!  There's very little, if
anything, that I've yet encountered which doesn't "work better" (at
least from a conceptual point of view) when "twisted into the filesystem
mold."  Mind you after having had the traditional ways pounded into my
head for so many years I sometimes have to have the new paradigm
explained in detail to me before I believe this myself even.

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 (eg. a meaningful /proc mkdir(), or a /proc
"fork" command [though of course with appropriate restrictions such as
only allowing the process itself to send such a command to itself a
"fork" command and having the read of the PID return zero in the parent,
etc. the latter would still make some amount of sense]).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>