If that is the case, we may want to think about the arguments and structures
that are passed into the kernels. What I mean is the following:
- Do we have to worry about things like "size_t" which differ between i386
and amd64 environments? What about 32-bit mode emulation/syscalls for
the amd64 kernels?
- Does it make sense to have a 64-bit type for something like "addresses"
defined for the userland/kernel interface, and have libc/libsystemcall/etc
translate the userland type (32-bit pointer, etc) to the fixed size the kernel
takes. For one simple argument this is not such a big deal, but when you're
dealing with structures that may change in size and alignment of their
various members, keeping backwards compatibility gets harder as time
moves onwards.
Down side is the cast/conversions on possibly both sides of the user/kernel
transition, possibly copying more bits than needed, needing to zero "extra"
portions during copy-out, etc.
-Toby.
On Sat, Apr 30, 2011 at 1:58 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
> ꀠ啱 think it's best to bump libc and also provide compat functions
> ꀠ沲or the syscalls that have changed. 澵truct ipc_perm also needs to
> ꀠ毪e updated (ours is still using unsigned shorts for things like the
> ꀠ濵id).
>
> ꀠ啱'll help finish things up at the sys_/kern_ separation stage if Jan
> ꀠ淸ets overwhelmed with the extra work. 啱 really want new kernels to
> ꀠ毪e compatible w/ release kernels. 啱 don't want to break compatibility
> ꀠ澑ight off the bat.
>
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt
>