Re: Allowing SYSV shared memory to allocated more than 2GB
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. 咗hat I mean is the following:
>
> - Do we have to worry about things like "size_t" which differ between i386
> and amd64 environments? 咗hat 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. 啫or 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:
>> ꀠ啱 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
>>
>
>
討論串 (同標題文章)
完整討論串 (本文為第 8 之 8 篇)：