Subject: re: COMPAT_IRIX and /dev/kmem emulation
To: Simon Burge <simonb@wasabisystems.com>
From: matthew green <mrg@eterna.com.au>
List: tech-kern
Date: 03/14/2002 13:12:44
   
   > Hi!
   > 
   > On IRIX, kmem diggers first ask politely to the kernel for the address
   > of the well known structures they are interested in. There is a system
   > call used for this. For instance, to get the load average, xload uses
   > sysmp() to get the struct loadavg offset in /dev/kmem. Then it reads
   > /dev/kmem and get the value.
   > 
   > I thought about emulating /dev/kmem itself for IRIX binaries. Our
   > sysmp() emulation can return the address of a dedicated structure, and
   > when the IRIX process digs /dev/kmem at that address, we could give it
   > the IRIX struct load_avg instead of the NetBSD one, thus making xload
   > working.
   > 
   > Is it a good idea? If it is, how to implement it? I thought about adding
   > a new device driver to sys/arch/sgimips/sgimips/conf.c. The device
   > driver would return translated structures when asked for well known
   > structures, and would return real kmem memory for other (or maybe
   > nothing, after all, there is no reason for which an IRIX binary could be
   > interested by our native kernel memory). The device node would fit in
   > /emul/irix/dev/kmem, of course.
   > 
   > Opinions?
   
   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.

actually, i don't agree.  there's going to be a limited set of
info that is required (such a loadavg) and doing the conversion
on the fly won't be that difficult.
   
   In general, I think supporting kmem grovellers under emulation is going
   to be far too painful to be useful...


if someone writes the code ....



.mrg.