curthread->t_procp->p_model in a zone

[Mark Phalan]

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

[Adam Leventhal]

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

Post by Mark Phalan
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
# dtrace -q -n 'BEGIN {printf("%x\n", curthread->t_procp->p_model);}'
200000
# 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

--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl