Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754774Ab1EVVP5 (ORCPT ); Sun, 22 May 2011 17:15:57 -0400 Received: from mail-qy0-f174.google.com ([209.85.216.174]:64103 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754927Ab1EVVPt convert rfc822-to-8bit (ORCPT ); Sun, 22 May 2011 17:15:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Fkam3Dpo8mNa59cDJec2HlXKH6Jlcu3YeKvfZqLtzgo5z2cOXZHID4NH6CktHkahb2 YsmW/9TBVduLio0An5putfUlfdAntTqE1IA7kWH0qLxhRtlZLw/FKtGOXvb3Zm5O80Nw PyACZ4W6P6U1nnhGaAvJ6XArExEm3BDvqA4/A= MIME-Version: 1.0 In-Reply-To: References: <201105211727.35985.arnd@arndb.de> <4DD80A91.5070302@intel.com> Date: Sun, 22 May 2011 14:15:48 -0700 Message-ID: Subject: Re: X32 project status update From: "H.J. Lu" To: "Anvin, H Peter" Cc: "x32-abi@googlegroups.com" , "arnd@arndb.de" , "gcc@gcc.gnu.org" , "libc-alpha@sourceware.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4153 Lines: 121 On Sun, May 22, 2011 at 1:02 PM, H.J. Lu wrote: > On Sat, May 21, 2011 at 4:48 PM, H.J. Lu wrote: >> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter 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@gmail.com] >>> Sent:?Saturday, May 21, 2011 12:39 PM Pacific Standard Time >>> To:?Anvin, H Peter >>> Cc:?x32-abi@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 >>> wrote: >>>> On 05/21/2011 09:27 AM, H.J. Lu wrote: >>>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote: >>>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/