🚀 go-pugleaf

chare@unilabs.uucp (Chris Hare) writes:

>In an attempt to understand more about how the kernel operates, I am trying
>to write a version of crash.  As a result, I will in several different
>instances need access to a processes u-block.  I would prefer to try and do
>this without having to make use of system-specific system calls, although
>if this is going to be the only method, then I guess I will have to resort
>to it.

The precise mechanism by which you get access to the u-block for a
process is inevitably going to be *very* system specific regardless
of whether you use a system call if one happens to be available
(eg the RDUBLK subfunction of sysi86() on Intel SVr3 and SVr4 systems)
or if you just go poking around in /dev/kmem and /dev/swap.

To be honest a lot of the stuff that "crash" does is inherently
very system specific since it has knowledge of internal kernel
data structures that may be implemented differently (if, indeed, they
exist at all) on different systems.

One of the secrets of writing portable code is to recognise which
parts of the code are inherently non-portable and implement those
functions in a separate module with a clean interface do that they
can be re-implemented easily when you have to port to another system.
Just put the function for accessing the u-block in a separate module,
implement it with whatever support is available on your system and
quit worrying about it ....

(Unfortunately, even if you *do* port this code to another system
I hope you realise that there is a good chance that the u-block you
get back won't look much like the one on the first system ....)

>(Unfortunately, even if you *do* port this code to another system
>I hope you realise that there is a good chance that the u-block you
>get back won't look much like the one on the first system ....)

And not all UNIX implementations (or "UNIX-compatible implementations")
necessarily even *have* U areas (SunOS 5.x might not, and some future
BSD might not, either).