Where do I find "u" (was in user.h) on 11.31?

[Stan Sieler]

Hi,
Am trying to port a kernel driver to HP-UX 11.31. On 11.23 (and earlier) I used
/usr/include/machine/sys/user.h ... which
doesn't seem to be on 11.31.
(That file contained "_u_default"
and "#define u _u_default")

I've installed various development pkgs,
and now have about 35 files in /usr/include/machine/sys ... but no user.h

Also, kernel lacks "_u_default" (and the older "uptr") variables. From Linux R&D, I suspect that r13 is a pointer to a user_t
variable, but that doesn't help me much
from C :)

Any pointers appreciated, thanks.

BTW, the 11i v3 Driver Development Reference
manual from HP refers to "u" in several places,
meaning either "u" should be available or that the manual has several bugs in it.
(HP Part Number: 5991-7749 Edition: E0207)

[Laurent Menase]

u is _u_default which is *uptr on pa system
- always the same adress in different segments.
but on IA system
u is _u_default which is a __thread user_t

[Laurent Menase]

apparantly it is missing when it should be included,
so contact hp support.

else you can use hpux 11.23 user.h since it had not been changed. - or very few only for lint-

[Stan Sieler]

Laurent said:

#1: [...] Yes, that's what I'd said.
Note, however, that 11.23 *HAS* "u".
I don't know if it's "correct" or not,
but it is (via a define):
extern __thread user_t _u_default;
i.e., presumably "thread correct".

#2: [...] nope ... I checked that before
posting :)

11.23's "user_t" is 3728 bytes long,
with u_ap at offset 2752.

11.31's "user_t" is 3984 bytes long,
with u_ap at offset 3224.

So...still looking for solutions :)

I may just try creating my own user_t typedef,
and using the declaration:
extern __thread user_t _u_default;
to get access to u.

Ah...maybe "tbss" means "thread bss"?
...it's not documented in "man nm" :(

thanks,
Stan
sieler@allegro.com

[Dennis Handly]

>I suspect that r13

Yes, r13 is TP.

>maybe "tbss" means "thread bss"?

Naturally.

[Laurent Menase]

Hi Stan,
struct user is not defined in user.h
for pa:
$ diff I80_11.23_LR I80_11.31_LR ;echo $?
0
for ia:
$ diff I80_11.23_LR I80_11.31_LR ;echo $?
50d49
< #ifdef _lint
52,56d50
< * FlexeLint does not recognize "__thread" keyword.
< */
< extern user_t _u_default;
< #else /* !_lint */
< /*
60d53
< #endif /* _lint */
1

Then
on PA system uptr has the same value for any thread/process. It is differianciated by the segment definition only!

on IA64 system uptr does not exist because the adress is not the same for every thread.
But we have the new __thread which define _u_default as a thread specific data.

[Laurent Menase]

You where talking about "u" only.
there are 2 different user.h.
one is defined in machine/sys/user.h
and is arch dependant and defines "u"
the second is common to ia64 and pa and is
in sys/user.h and define struct user
You should contact hp response center or dspp (http://h21007.www2.hp.com/) group to get those file.

[Laurent Menase]

of course the user.h for which I put the diff is machine/sys/user.h, the one which defines "u" like asked in the question.

[Laurent Menase]

http://h21007.www2.hp.com/dspp/fback/fback_SendFeedback_IDX/1,1291,10,00.html


but apparantly it is something wanted to not deliver it anymore for modularity purpose. So it may be changed anytime without any notice to third party.
but interface functions had been defined.


What do you need to access in user structure exactly? there is may be some solutions.
for instance to get the current thread pointer you have kthreadp_self(void) defined in sys/kthread.h

[Laurent Menase]

in fact you can find all those interface function at
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,10109,00.html
in the DDR.

[Stan Sieler]

Re:

Laurent writes:
in fact you can find all those interface function at
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailP
age_IDX/1,1701,10109,00.html
in the DDR.

I mentioned at the start that I had looked
at the DDR (giving the part number of the
manual :) I didn't specify that I looked
at every page, however. The guide lacks
*many* of the interface routines of the
kernel ... it primarily lists those thought
to be of interest to the device writer,
not all routines in the kernel. Further
searching shows not a single interface
to "u" for anything concerning system
calls (e.g., u_ap, u_nargs, u_error).

Indeed, the DDR (as I mentioned at the start)
implies that "u" is available (e.g., u.u_error).


Re: Laurent writes:
> But we have the new __thread which define
> _u_default as a thread specific data.

I forgot to mention that the 11.23
/usr/include/ia64/sys/user.h includes:
extern __thread user_t _u_default;
...I mostly omitted mentioning it because
there is no same-named user.h file on any 11.34
system I've seen so far.

I could, as I suggested earlier, define
my own user.h (with hopefully correct layout)
and declare my own:
extern __thread user_t _u_default;

...in fact, I'll try that now...

bingo...seems to work...somewhat.

However, although I'm seeing u.u_ap correctly,
u.u_nargs seems to be 0.

[Stan Sieler]

Seems like u.u_nargs is set from sy_nargs
instead of from the actual number of parameters passed in.

(That may be a bug, insofar as the
programmer would expect the user-callable
"syscall()" routine (which accepts a
variable number of arguments) to pass in
nargs).

[Laurent Menase]

Hi Stan,

It is something which was intentionally done to remove "u" from public interface.

But you are right some of the interface functions are missing.

u.u_error interface is clearly missing and
is indeed present 3 times in the DDR.
and one time where it is needed to be used:
the driver_select(9E)
For the other, u_nargs had always been for debug purpose, and has always been sy_narg.


u_ap is to be used if you are writing a syscall and not a driver.

If it is the case, and you need the u_ap and different fields of struct user, then contact the DSPP or hp support and ask for an enhancement there. - DSPP should be more appropriated in that case-.

[Stan Sieler]

My driver installs syscall intercepts :)

I call it a "driver" only because I
communicate with it via ioctl() ... it's
real purpose is to intercept/modify
certain system calls for users.

And, it would seem to have to be a driver
because there doesn't appear to be any
other mechanism of adding code to the
kernel (and getting it invoked at some time).
(I'd design/donate one, but not without
an assurance that it would be accepted/used :)

Stan
sieler@allegro.com

[Laurent Menase]

Hi Stan,

A pair of interface functions are defined in
sys/syscall_kernprivate.h:
I think I have found the functions you need:
scall_argp(void) returns u.u_ap;
set_scall_argp(scall_arg_t *argp) set u.u_ap
scall_rvalp(void) Return a pointer to the system call return value(s)
scall_num(void) return the syscall number
set_scall_num(scall_num_t num)
scall_error(void) get the u.u_error
set_scall_error(int error) set u.u_error
scall_qsave(void)

[Stan Sieler]

Hi Laurent,

thanks for the pointer to sys/syscall_kernprivate.h ...
it has a number of useful routines for
defining my own system call.

I'd looked at it in 11.23, but had
overlooked it for 11.34.

On 11.23 (and earlier), it doesn't have anything of the form "scall_...",
but that stuff is there on 11.34, thanks!

[Laurent Menase]

Hi Stan,
Indeed this is new for 11.31. On 11.23 you still need to use struct user and "u" defined in sys/user.h which includes machine/sys/user.h