From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 049D71F405 for ; Wed, 19 Dec 2018 19:57:30 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=XhvRFnmnVwmlwkWe +mimeKWsvXImWyLfXmWs2Y2OPx49pFI+Q66iCwWc5b2yRkDC8vdwn8KEev3t2/D4 sykqzep5MupRi76tK22FTmIKjaMAV3Qzl4TcxQqr9J6OUFPD3g4ZqHxKwHD9VO+g Se9mOgCiB/R6KUhoivOLW6otVkY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=8amV8Bv5cYiiXrvwlDAdyc EP/F4=; b=RAdB2j5tHmWRbCwpnVn2QI8YtgC/2bM0AZF0MiA5oYjGRhFnupUsON mD+7oF/cPSlVMOlHM1est5g5GZcIaxIhbinoCdOHRoH9KKqNlCxft7QGrxhlJkqW KnsnJ1wzCHsGSTj9lIFhS+T//J8GDZoNG6CdGBbk1qqQu6GSDmkIE= Received: (qmail 58109 invoked by alias); 19 Dec 2018 19:57:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 58086 invoked by uid 89); 19 Dec 2018 19:57:26 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: smtprelay.synopsys.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1545249443; bh=5/YgvQsSLv1gwyqs+Gv+Cy2br7VDOdcJIbXEkBJVmuI=; h=Subject:To:CC:References:From:Date:In-Reply-To:From; b=ZkBKRaDCBqFIV1qVl0agAuzSjFkI/7ofsYhlezjqT69KYWTh4His+L6k4frTDhpNS pAao91jNIxoGhYwavMy7+um25V2OebIh8FW33HZQD8Jo3DKGTzFZcSUwHCmTiAMAEN KbwuXDGDcMzVqPSv8zkXS74IN3R7Izk6A9KS7Q7WsVuOnZIrk7R5AfEyq9Y/cx4s8h TdBNZz7R8fOOp/b3X+K19ymT9cAfQ+GJlXMHPnBstjwC1nEjltpURgUD+LpllBoEuH k0Ro/lS9pqVxFTJhTOLkmDYmtyftWlWNG5D3r2isaJ08hqV6QvRqlyAptQcjQG8d+c 3vfMg+ZxI5suQ== Subject: Re: [PATCH 09/21] ARC: Linux ABI To: Joseph Myers CC: Adhemerval Zanella , , Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel.arc References: <1545167083-16764-1-git-send-email-vgupta@synopsys.com> <1545167083-16764-10-git-send-email-vgupta@synopsys.com> From: Vineet Gupta Openpgp: preference=signencrypt Message-ID: Date: Wed, 19 Dec 2018 11:57:13 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 12/18/18 3:38 PM, Joseph Myers wrote: > On Tue, 18 Dec 2018, Vineet Gupta wrote: > >> +typedef unsigned short int __pr_uid_t; >> +typedef unsigned short int __pr_gid_t; > > Are you sure? No I'm not :-) There were some interim sweeping changes in this area since when I started so this might indeed be redundant as you say. > I don't see an ARC-specific definition of __kernel_uid_t or > __kernel_gid_t in the Linux kernel at all (which would mean unsigned int > is actually used and you don't need this header at all). I'll check. >> diff --git a/sysdeps/unix/sysv/linux/arc/bits/sigaction.h b/sysdeps/unix/sysv/linux/arc/bits/sigaction.h > > I wouldn't expect new architectures to have their own bits/sigaction.h. > Rather, I'd expect them to use the generic bits/sigaction.h and the > generic code to convert from the userspace struct sigaction to the kernel > version. So this is further to the other thread about generic sigaction (sorry for cross-post). Indeed with switch to generic sigaction this may not be required. *However* the layouts of generic userspace sigaction are different from kernel's. Just to rehash (notes for myself really) 1. user exported struct struct sigaction { __sighandler_t sa_handler; __sigset_t sa_mask; int sa_flags; void (*sa_restorer) (void); }; 2. Linux kernel UAPI struct sigaction / glibc kernel_sigaction struct sigaction { __sighandler_t sa_handler; unsigned long sa_flags; __sigrestore_t sa_restorer; sigset_t sa_mask; /* mask last for extensibility */ }; Since they don't match and we can't possibly change kernel_sigaction, a future optimization implies changing #1 which has ABI implications at which point it has diminished or NO returns. So perhaps we keep the ARC header above, with matching layout, while switching to generic sigaction() still. OK ? >> +#ifdef __USE_MISC >> +# define __ctx(fld) fld >> +#else >> +# define __ctx(fld) __ ## fld >> +#endif > > New ports should just use namespace-clean field names here > unconditionally. The __ctx macros with __USE_MISC conditionals are purely > for maximum API-compatibility for existing ports that needed to be fixed > to make them namespace-clean. OK, fixed this. Thx, -Vineet