Subject: Re: ps_strings addrress (was: new sysctl(KERN_PROC, ...) interface)
To: Simon Burge <email@example.com>
From: Eduardo Horvath <firstname.lastname@example.org>
Date: 04/20/2000 08:43:10
On Thu, 20 Apr 2000, Simon Burge wrote:
> Simon Burge wrote:
> > 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.
> Am I right in saying that the stack on sparc64 for a 64bit native and
> 32bit emul process both are at USRSTACK=0xf1000000, and PS_STRINGS
> always allocates room for a 64 bit 'struct ps_strings' either way?
> sparc64/sparc64/netbsd32_machdep.c doesn't seem to do anything
> different in this respect...
Ignore the current implementation; I don't know what I'm doing 8^).
I believe that is a correct description of the current code. It was done
that way so the 64-bit PS can find the PS_STRINGS. Whether that's the
correct implementation or the 32-bit emulation PS_STRINGS should use
32-bit pointers is a moot point. You have incompatibility one way or
On the USRSTACK issue: the 64-bit stack base will be moved up into 64-bit
space eventually. (I am undecided whether to move kernel up to
0xffffffff00000000 or leave the kernel where it is and make the user and
kernel address spaces disjoint. Do any other ports have disjoint kernel
and user address spaces?)