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

[Kedar Soparkar <kedarsoparkar@xxxxxxxxx>]

On Sun, May 1, 2011 at 1:52 AM, Tobias Weingartner <weingart@tepid.org> 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
> <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
>>
>
>