On Sun, May 22, 2011 at 1:02 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Sat, May 21, 2011 at 4:48 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter <h.peter.an...@intel.com> >> 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.to...@gmail.com] >>> Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time >>> To: Anvin, H Peter >>> Cc: x32-...@googlegroups.com; 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.an...@intel.com> 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.to...@gmail.com> wrote: >>>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <a...@arndb.de> 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.
