Interfaces for accessing kernel memory

[Barry Shein]

>There's certainly no reason that it has to be implemented as a system
>call.

Security is one consideration as most people like to keep /dev/kmem
unreadable. But then again, a library would be more than useful for
people developing privileged programs (certainly no *worse* than the
current situation, and would work when/if the table() call became a
common syscall.)

Another, more subtle, consideration and one reason encore put this
sort of stuff into system calls is that on multiprocessors the
likelihood that the table you're looking at won't be "corrupted"
(changed) as you read it becomes fleetingly small. At least a syscall
can, optionally, lock the structure while it's being copied out.
There's almost no way to do that thru the regular read/write interface
on /dev/kmem (well, you can do anything, look at what the guy is
reading etc, but forget it, a syscall here solves a real problem.)

A library emulation would be a good idea. It would be a way for people
to start moving their favorite utilities over and break the old
chicken and egg compatability problem (and create a demand.)

Should have been done years ago.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD