Darren Reed wrote:

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

Look at the convoluted dance that the _kvm_uread function does in the
top of lib/libkvm/kvm_proc.c.  If we change the vm system internals,
then that obviously fails in the backwards compat case.

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

Any way of getting the address of ps_strings is bad?  Do you mean keep
{argv,environ} in a fixed sized buffer?  If so, this would make 1) above
moot...

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

From what I understand, a 32 bit binary can't have a va > 4GB, even on
fancy(?) segmented architectures.  Yes, pointers are being a hassle :-)

Simon.