From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 447 invoked by alias); 7 Nov 2016 13:17:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 430 invoked by uid 89); 7 Nov 2016 13:17:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2461, suffice X-HELO: mail-ua0-f169.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4zV+JUV1e/D2w7+LHAP5RLeBL0dTlqkID0YdSNtqsmY=; b=MfFLd8ywu/OKCc7VQx1V2v/yu9sZe4fc7remhxhMX/yWN4EReFZz7vLW3kB8g+gmX3 mi50dt8ETfi81B75kgeN4Hu/qxDVk8AdRA90hopM+xYnb+tXnno2lMmni+C2BbRVYjec jaKXFeA4UT7YmKhUvR4rSe1a50H3eBY2e7PT3m7Uvokqqp1qO0qU5VIRPcxBUGhPN6/v l+YEkhx9EHqgzYr3mT9cYP31QsMUKXlahikc1042tMBljntOaUlwaLBz437wRjLSDOYk bsYf5IRMJlgIf2E+dBuwk5zDohl27uuSDU0GKmpgCpo4+2Ey4WPQm0byMiUcITU0o6KP OPGA== X-Gm-Message-State: ABUngvcCoIenCJTzLkhcskCucdXjCdkCQp2mVwdcqilcuhSouEvupWIRDUbuvGfDVYEAAWgs X-Received: by 10.176.5.130 with SMTP id e2mr3783974uae.108.1478524662024; Mon, 07 Nov 2016 05:17:42 -0800 (PST) Subject: Re: [PATCH v2 01/16] Add __ASSUME_SYSVIPC_SYSCALL for Linux To: Arnd Bergmann , libc-alpha@sourceware.org References: <1478114813-3526-1-git-send-email-adhemerval.zanella@linaro.org> <1478114813-3526-2-git-send-email-adhemerval.zanella@linaro.org> <3237762.biBvPUTa3n@wuerfel> From: Adhemerval Zanella Message-ID: <7f12c0e6-6601-9317-2aff-4b276f1b4daa@linaro.org> Date: Mon, 07 Nov 2016 13:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3237762.biBvPUTa3n@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00231.txt.bz2 On 07/11/2016 09:28, Arnd Bergmann wrote: > On Wednesday, November 2, 2016 5:26:38 PM CET Adhemerval Zanella wrote: > >> The architectures that only supports ipc syscall are: >> - i386, m68k, microblaze, mips32, powerpc (powerpc32, powerpc64, and >> powerpc64le), s390 (32 and 64 bits), sh, sparc32, and sparc64. > > If you want to mention the architectures not supported by glibc, this > also includes > > cris, frv, m32r, and mn10300 > I think for commit/code comment mentioning only the supported archs should be suffice. >> And the architectures that only supports wired syscalls are: >> - aarch64, alpha, hppa, ia64, mips64, mips64n32, nios2, tile >> (tilepro, tilegx, and tilegx64), and x86_64 > > similarly, this also includes > > arc, avr32, blackfin, c6x, h8300, hexagon, metag, openrisc, score, > unicore32, and xtensa > >> Also arm is the only one that supports both wire syscalls and the >> ipc, although the ipc one is deprecated. > > AFAICT, ipc syscall on ARM is only defined for OABI, which glibc > no longer has. Indeed, I think I should note that glibc's supported arm eabi should use wire syscalls (although for a source standpoint it will still see __NR_ipc defined). > > From the kernel sources, I also see sh64 and microblaze define > both __NR_ipc and the individual numbers, although microblaze > returns -ENOSYS for ipc(). Indeed, in my first analysis I did not filter 'sys_ni_syscall' while checking the syscall table in kernel files. With this checked microblaze should that ipc is defined as 'sys_ni_syscall'. > >> This patch adds a new define, __ASSUME_SYSVIPC_SYSCALL, that wired >> syscalls are supported on the system and the general idea is to use >> it where possible. > > We might add the individual syscalls on all architectures at some point > in the kernel, including the ones that currently use the combined > ipc call. A patch series for this has been discussed in the past, > but I think we never fully resolved the handling of the IPC_64 > flag, so it did not get merged so far. > > With your current approach, this won't cause problems as architectures > that don't have the individual calls with old kernel versions will > still use the ipc() wrapper in the kernel. > That's the idea and if a architecture eventually adds wire ipc support it just need to correct undefine __ASSUME_SYSVIPC_SYSCALL within correct kernel header version. > > Arnd >