DragonFly kernel List (threaded) for 2011-05
[Date Prev][
Date Next]
[Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
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. 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
>>
>
>
[Date Prev][
Date Next]
[Thread Prev][
Thread Next]
[
Date Index][
Thread Index]