From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Subject: Re: Nonstandard /proc? (Re: /proc directory, dosemu, and boot questions) Date: 4 Aug 1993 04:54:13 GMT
>Mark J. Everett (everettm@merlin.think.com) wrote:
>
> SVR4 procfs has just one file per process in /proc which basically
> provides access to the process' memory image. Other control is
> provided by ioctl()s. Is there some reason, other than NIH (Not Invented
> Here) that a new 'procfs' was used instead of re-implementing the
> SVR4 version? IMHO, it seems like we've locked ourselves out of
> potential future software, because the original wasn't followed.
> Or has procfs also been changed? Its been a few years ...
There's a couple of reasons not to copy the SVR4 /proc - one that it
is not very well designed or implemented, and technically inferior to
the existing linux one (but has some more features that linux needs to
add to /proc *). The other is that the design of SVR4 /proc is going to
change a lot in SVR4.2 (or later) anyway to look much more like the Linux
(or Plan 9) one. One of the reasons for this is so that /proc can be
exported across nfs, like Linux /proc can now, for remote debugging.
SVR4 /proc isn't that portable anyway -- any software that uses such
interfaces should be written with a portable process control interface,
and can't expect to be binary compatible.
J
*) Linux needs more features in /proc for controlling processes rather
than just watching them. ptrace(2) is a hack and very broken for
debugging processes under linux. There needs to be some mechanism doing
the same things as the SVR4 PIOCRUN, PIOCWAIT etc. It would probably
be easier to add these to /proc rather than writing a new /proc-like
filesystem with the implementations in it, tho the code and mechanisms
should be shareable.