Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
To: Simon Burge <simonb@netbsd.org>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-kern
Date: 04/18/2000 19:58:45
In some email I received from Simon Burge, sie wrote:
> So, a quick summary of the problems so far:
> 
>  1) Need a way to read a given va for a process, without resorting to
>     frobbing vm internals.
> 
>     Possible solution: add
> 
>         sysctl(CTL_KERN, KERN_PROC_VA, pid, va, &type, &offset);

What is this needed for ?

>  2) Need a way to get the address of the ps_strings struct for a given
>     process - this can vary per process on a machine running both 32 and
>     64 bit processes.
> 
>     Possible solutions: add
>         
>         sysctl(CTL_KERN, KERN_PROC_PSADDR, pid, &va);
> 
>     or keep address of ps_strings in struct proc and pass back inside
>     struct kinfo_proc2.

This is bad.  As much as others may detest it, I'd go for putting this
information in a static sized buffer.  If people do "ps axwww" or "ps e"
then it should fall back, as required, to a method which supports the
return of architecture dependant sized structures.

Another option is to create something like this:

struct foo {
        union {
                uint64_t        u64;
                uint32_t        u32;
        } fu;
}

and conditionally fill the appropriate part in the kernel.

For 32bit binaries running on a 64bit system, it may also be that the
pointer once squeezed into 32bits no longer makes sense - for example
when user applications have an address space > 4GB.  So again, if you
really want to be 32bit compatible, don't return any pointer information.

Darren