Re: X32 project status update

[H.J. Lu]

On Sun, May 22, 2011 at 1:02 PM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote:
> On Sat, May 21, 2011 at 4:48 PM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote:
>> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter <h.peter.anvin@xxxxxxxxx> wrote:
>>> I'll look at it but possibly not until the weekend.
>>
>> I checked it into hjl/x32/syscall branch at
>>
>> http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary
>>
>
> We need to investigate if we need to have different x32 syscalls for
>
>        .quad sys32_fanotify_mark
>        .quad compat_sys_open_by_handle_at
>        .quad compat_sys_clock_adjtime
>        .quad compat_sys_sendmmsg       /* 345 */
>
> My guess is yes for the last 3 and unsure for fanotify_mark.

There is no need for x32 fanotify_mark.  I updated hjl/x32/syscall branch
for the other 3 system calls.  Should we regroup x32 system calls?

I added

/* Need it before vDSO is enabled.  */
#define __NR_x32_getcpu                         402

since vDSO isn't enabled for x32.  It should be removed/disabled after
x32 vDSO is supported.

H.J.
>> ---
>>> -----Original Message-----
>>> From: H.J. Lu [hjl.tools@xxxxxxxxx]
>>> Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time
>>> To: Anvin, H Peter
>>> Cc: x32-abi@xxxxxxxxxxxxxxxx; Arnd Bergmann; GCC Development; GNU C Library;
>>> LKML
>>> Subject: Re: X32 project status update
>>>
>>> On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
>>> <h.peter.anvin@xxxxxxxxx> wrote:
>>>> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>>>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote:
>>>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>>>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>>>>> This is the x32 project status update:
>>>>>>>>
>>>>>>>> https://sites.google.com/site/x32abi/
>>>>>>>>
>>>>>>>
>>>>>>> I've had another look at the kernel patch. It basically
>>>>>>> looks all good, but the system call table appears to
>>>>>>> diverge from the x86_64 list for no (documented) reason,
>>>>>>> in the calls above 302. Is that intentional?
>>>>>>>
>>>>>>> I can see why you might want to keep the numbers identical,
>>>>>>> but if they are already different, why not use the generic
>>>>>>> system call table from asm-generic/unistd.h for the new
>>>>>>> ABI?
>>>>>>
>>>>>> We can sort it out when we start merging x32 kernel changes.
>>>>>>
>>>>>
>>>>> Peter, is that possible to use the single syscall table for
>>>>> both x86-64 and x32 system calls? Out of 300+ system
>>>>> calls, only 84 are different for x86-64 and x32.  That
>>>>> is additional 8*84 == 672 bytes in syscall table.
>>>>>
>>>>
>>>> Sort of... remember we talked about merging system calls at the tail
>>>> end?  The problem with that is that some system calls (like read()!)
>>>> actually are different system calls in very subtle situations, due to
>>>> abuse in some subsystems of the is_compat() construct.  I think that may
>>>> mean we have to have an unambiguous flag after all...
>>>>
>>>> Now, perhaps we can use a high bit for that and mask it before dispatch,
>>>> then we don't need the additional table.  A bit of a hack, but it should
>>>> work.
>>>
>>> How about this patch?
>>>
>>>    Merge x32 system calls with x86-64 system calls
>>>
>>>     Implemented with
>>>
>>>     1. Mark all x86-64 specific system calls with __NR_64_.
>>>     2. Mark all x32 specific system calls with __NR_x32_.
>>>     3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
>>>     build, which provides __NR_ versions of x86-64 specific system calls.
>>>     4. Append x32 specific system calls after the current x86-64 system
>>>     calls.
>>>     5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
>>>     _NR_.
>>>     6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
>>>
>>> --
>>> H.J.
>>>
>>
>>
>>
>> --
>> H.J.
>>
>
>
>
> --
> H.J.
>



-- 
H.J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/