Emmanuel Dreyfus wrote:

> > 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.

Ah, this sounds much more reasonable.

How much of this do you want to emulate?  Enough for just xload and
similar programs, or all the way up to more complex grovellers like
ps and netstat?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/