Question abt /etc/crash & proc struct

[Melinda Shore]

In article <8633 at awdprime.UUCP> moody at snap.austin.ibm.com writes:
>No one would want user mode programs to have access to this structure.

It is not at all clear what you mean by this.  If you mean that no
program outside the kernel should be able to access the proc table,
that's obviously incorrect.  If you mean that the pages containing the
proc table should be protected by the mmu, that's less obviously
incorrect, but incorrect nevertheless.

One of the very basic paradigms in Unix is that of a file.  Granted,
it hasn't been implemented very consistently (particularly in BSD),
but the basic notion is that most system objects can/should be able
to be treated like a file, including memory.  You should be able to
open, read, write, and lseek around in both physical and kernel
virtual memory.  Access permissions are set in the inode, not the
page table (sheesh), and users are granted permission to read, write,
etc., memory just as they are with files - on the basis of the 
permission bits in the inode.  Taking away that facility is *not* an
improvement.

That's not to say that there shouldn't be system calls to copy kernel
data structures out to user space.  They do simplify programming and
considerably improve the performance of programs that grab data out
of the kernel.  That still doesn't justify removing a flexible,
powerful, and idiomatic facility.

Also, note that some of us are running AIX/370 and don't have getproc().
-- 
                    Software longa, hardware brevis
Melinda Shore - Cornell Information Technologies - shore at theory.tn.cornell.edu