Hey Mark,
Unfortunately we don't have a good answer today for non-global zones or DTrace
consumers without the dtrace_kernel privilege. A good RFE would be to add, say,
pstatus_t or something else from proc(4) for less privileged DTrace uses.
Adam
On May 11, 2010, at 7:36 AM, Mark Phalan wrote:
>
> I'd like for my provider to work properly with both 64 and 32 bit user
> processes and for that I need to be able to distinguish them at runtime.
>> From what I've seen the way people are doing that is by looking at the
> value of
>
> curthread->t_procp->p_model
>
> This works fine in the global zone:
> # dtrace -q -n 'BEGIN {printf("%x\n", curthread->t_procp->p_model);}'
> 200000
>
> but not very well in a non-global zone:
>
> # dtrace -q -n 'BEGIN {printf("%x\n", curthread->t_procp->p_model);}'
> dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid
> kernel access in action #1 at DIF offset 0
>
> I presume this is failing due to the lack of the dtrace_kernel privilege
> (which cannot be granted to a zone).
>
> Is there a better way to determine whether or not a user process is
> 64bit which works in a zone?
>
> Thanks,
>
> -M
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
