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