Re: Allowing SYSV shared memory to allocated more than 2GB

[Tobias Weingartner <weingart@xxxxxxxxx>]

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:
>    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
>