[robert@par.univie.ac.at (Robert Mayer - Student) writes:]
>2. mmap() kernel memory at an address I can access.
Yes, mapping physical memory would be a useful, general mechanism worth
adding to the kernel. However there's a completely different approach which
you might consider. The problem with reading kernel memory is (1) your code
can break each time the kernel changes, and (2) you can't really trust the
results, as the data structures can change out from beneath you.
If you add a kernel interface to query process status (HP-UX called it
pstat()--I made it up for them, so I've seen this work before) then you can
have it communicate using an interface which insulates the /proc server from
changes to the kernel. It can also protect against race conditions, as the
kernel side of pstat() can apply the locking necessary to guarantee that the
information on a given process/thread was consistent for the instant in time
it was taken.
Your current approach has the nice characteristic that it doesn't put more
stuff into the kernel. Allowing the process read-only access to kernel
memory opens some security holes, but the lack of write access limits these,
and it probably is tolerable.
Anyway, another way to consider. Adding a mmap() of physical memory would
be the work of an hour or so, let me know if you'd like me to do it,
although you're welcome to have a go at it yourself. Please be wary of
multiprocessor issues!
Regards,
Andy
Received on Sun Mar 27 10:28:20 1994
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:02:16 PDT