> My first thought is that this would be unscalable.  I suspect that there
> would be very few, if any, kernel structures that the kmem grovellers
> can use untranslated so you'd need to provide some sort of temporary
> storage for the translated structures and then you have the issue of how
> long those temporary structures survive and how they'd get updated.

Let me rephrase, I have not been clear enough:
xload calls sysmp() to get load_avg address. NetBSD's kernel returns
&irix_load_avg, which is a dummy int that won't be used anywhere.

Then I have an IRIX kmem driver, that xload will open instead of the
real /dev/kmem, and it would do something like this on read operations
        
if (offset == &irix_load_avg) {
        struct irix_load_avg ilavg;
        
        (build ilavg from native load avg)
        copyout(buf, &ilavg, len);
}

Hence there is no need to update, the data is build on the fly when
xload tries to read it.

> In general, I think supporting kmem grovellers under emulation is going
> to be far too painful to be useful...

I only though ablout doing it for IRIX, because kmem grovellers don't
get the offset of what they are looking for by reading the kernel symbol
table: they have a system call for this. Without such a system call, you
cannot know where the kmem groveler is going to read its data from
(because you are not giviing this information), and hence you've got no
opportunity to translate it.

-- 
Emmanuel Dreyfus
manu@netbsd.org