Darren Reed wrote:

> In some email I received from Simon Burge, sie 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.
> > > 
> > > 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...
> 
> Not keep, but copy out to when doing the sysctl() (or is that what you
> mean here ?) - ie do what ps does with ps_strings for it, upto a limit
> of course.

So add a

	sysctl(CTL_KERN, KERN_PROC_ARGV, pid, buf, len)
and
	sysctl(CTL_KERN, KERN_PROC_ENVP, pid, buf, len)

?  Hmm, not sure...  Would certainly make user land users easier, but
I'm equally at home keeping as much of the functionality as possible in
libkvm and just having the necessary kernel help to get things right.
Any other opinions on this idea?

> Re. displaying wait channel, etc, hmmm....I think you have to bite the
> bullet and force them to always be 32bit or always be 64bit for the
> purposes of this new sysctl.

That's the plan - it'll always be a 64 bit quantity, no matter how big
machine pointers are.  Until we get 128 bit CPUs!

> The other thing which may bite is changes to field width when formatting
> for 32/64bit when showing pointers.

I've tinkered in the past a little with field display aligntments.  In
the scheme of things, this should be the least of our problems :)

Simon.