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 <[email protected]> wrote: > I think it's best to bump libc and also provide compat functions > for the syscalls that have changed. struct ipc_perm also needs to > be updated (ours is still using unsigned shorts for things like the > uid). > > I'll help finish things up at the sys_/kern_ separation stage if Jan > gets overwhelmed with the extra work. I really want new kernels to > be compatible w/ release kernels. I don't want to break compatibility > right off the bat. > > -Matt >
