1. Despite the comment, aren't the u_int fields of different sizes in
32- vs 64-bit builds? The comment seems to be somewhat misleading.
u_int is 32 bits in both ILP32 and LP64, so it is fine. It would have
been better to use uint32_t instead.
2. Is there any assurance that the module's load address (in ms_addr)
can fit in a uint64_t?
Yes, for all platforms (currently). If it was uintptr_t be it would have
been different size in ILP32/LP64.
3. If I wanted to add another address field (ms_modaddr for the address
of the module's 'struct module'), would it be better to
a) insert a new uint64_t in the middle of this structure,
after the current ms_addr field,
b) insert a new uint64_t in the middle of this structure,
immediately before the ms_reserved[] array,
c) append a new uint64_t at the end of this structure, or
d) replace some number of the ms_reserved[] array with a
new uint64_t structure (and how many to replace?)
You need to replace 2 u_ints (each u_int has 4 bytes and you need
8 bytes for a uint64_t).
Thanks for the quick responses.
Since the real reason I was contemplating this was to get access to
the mod_flags member of struct module, I decided it was more correct
to directly expose that value, rather than providing a kernel address
of the structure (and then having to use gdb/crash to examine it).
+------------------+--------------------------+-------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+-------------------------+
