According to der Mouse:

>>>> It would be A Cool Thing [TM] if one could say
>>>> 'echo KILL > /proc/<pid>/ctl' and the process would die... (subject
>>>> to normal access controls, of course).

>I believe it already works this way, though you may have to say kill
>rather than KILL.

>>> If you want to take this further, why not "rmdir /proc/<pid>" as kill -9?

>Heh. :-)

>>> It's easy to get carried away with this though, [...]

>> Hey Cool!  Then we can replace most system calls with file
>> operations.  We can deprecate everything to unlink(), mkdir(),
>> read(), open(), creat(), write(), lseek() and close().

>Yup.  In many ways I'd like to see that happen.  (Though I'd dump
>creat(), since it's subsumed by modern open().)

>Hm, have to add rmdir().  Or were you going to have unlink, applied to
>a directory, turn into rmdir?

Why not? (mkdir is just a special case of mknod) rmdir is just a kluge
so that lusers can't destroy filesystems by reducing the link count
on directories. unlink should be able to handle that cleanly.

>> Oh, and lots of new ioctl() to handle the "other stuff".

>No, as someone else already said, just open the ctl file and read/write
>it.  The only excuse for ioctl is code that needs to do things when
>handed just a file descriptor, like stdio doing a TCGETA on stdout.
>I'm not sure how to address that.

If it's handed an fd, then surely it can grok /proc/<pid>/fd and do
a write on a /proc/<pid>/fd/xxx/ctl, where xxx is the file descriptor.

When you have a paradigm, you may as well pursue it to its ultimate
stupidity :-)

BTW: what could one do about select() or poll()? create a list of the
appropriate /proc/<pid>/fd/xxx/{read,write,except} files to a special
/proc/<pid>/select?  That way, you could, given permissions,
select/poll on other, unrelated processes too.

The bind moggles. Or does it already work that way?

-- 
Bernd Felsche {speaking for himself}
MetaPro Systems Pty Ltd, 130 Fauntleroy Avenue,
Redcliffe, Western Australia 6104
Phone: +61 9 479 3722    Fax: +61 9 479 3720