On Sun, May 1, 2011 at 1:52 AM, Tobias Weingartner <[email protected]> wrote: > 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?
32-bit emulation for amd64 kernels does not exist currently. > - 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. Agreeable, but can be remedied if the structures are parsed into newer formats without user intervention. > 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 >> > >
