In article <1992Feb16.201353.27740@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
quoted text
>
>There is not, almost by definition, any "compatibility" issues with
>/dev/kmem unless the kernel structures are identical.  What use is it
>to open /dev/kmem and suck up the proc structure when its not at all
>what the user program expects?
>
>I agree 100% with Chuck; having written programs that have to grovel
>around in kernel memory, I'd prefer to have a well defined interface
>to return the information that I need.  I certainly don't WANT to use
>/dev/kmem in my programs; I just have no other choice.  That means on


Yes, and exactly what *is* that well defined interface?  I've followed
this discussion for a while now, and noone has mentioned that /dev/kmem
actually has a lot of advantages over added system calls.  If you decide
to collect different stats from the kernel, with /dev/kmem you just
recompile ps to read out different stuff.  Using system calls can require
rewriting the kernel to get what you want, either adding a new system call
or changing an old one in an incompatible way -- and then you still have to
recompile ps.  This is even more work.  And remember, ps isn't the only
program that we're discussing here.  We might want netstat and vmstat and
probably others I'm not familiar with.

As to Charles Hedrick's comment that modern Unices are moving away from
reading special files towards adding more system calls:  Well, that's
debatable.  As a counterexample, consider /dev/proc vs the extremely
bletcherous ptrace system call.

Are there any Unices that actually use a system call to implement ps?
If not then I think that we might want to very carefully consider why.

--
Doug Quale
quale@saavik.cs.wisc.edu