From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64134 invoked by alias); 22 Apr 2017 13:45:32 -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 64095 invoked by uid 89); 22 Apr 2017 13:45:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=lake, H*RU:sk:ppp-88-, H*r:sk:ppp-88-, Hx-spam-relays-external:sk:ppp-88- X-HELO: mail-out.m-online.net X-Auth-Info: MT9XtK4dp/nZnkX0EU1T8IArPZq2zpzHciguEwUEKs95nToYd2e4jGVyQESC1+/l From: Andreas Schwab To: Florian Weimer Cc: Carlos O'Donell , libc-alpha@sourceware.org, "Dmitry V. Levin" Subject: Re: [PATCH] : Use an arch-independent system call list on Linux References: <086d58f4-f74c-6b8b-52f7-e7b80c51bb40@redhat.com> <20170406143719.GA29170@altlinux.org> <1fd1a90c-1f79-5eef-d9d4-aef7ccc4965c@redhat.com> <87shl2x7xo.fsf@linux-m68k.org> <8737d1y6zo.fsf@linux-m68k.org> <87shl1vbsn.fsf@mid.deneb.enyo.de> <87pog5wpdh.fsf@linux-m68k.org> <87k26dvagc.fsf@mid.deneb.enyo.de> <87lgqtwo4i.fsf@linux-m68k.org> <87fuh1v9fu.fsf@mid.deneb.enyo.de> <87h91hwnus.fsf@linux-m68k.org> <87a879v8hz.fsf@mid.deneb.enyo.de> <87d1c46au4.fsf@linux-m68k.org> <878tmsac0q.fsf@mid.deneb.enyo.de> X-Yow: Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS -- Date: Sat, 22 Apr 2017 13:45:00 -0000 In-Reply-To: <878tmsac0q.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Sat, 22 Apr 2017 13:59:33 +0200") Message-ID: <8737d05zf0.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-04/txt/msg00492.txt.bz2 On Apr 22 2017, Florian Weimer wrote: > This does not work for some distributions because the order is like > this: > > * Rebuild glibc for a point release. > * Backport a system call to the actual kernel package. > (* Backport the system call addition to the kernel headers package.) > > Whether the last step happens or not is immaterial in this context. > You won't get the SYS_ macro with this build order. Which your patch won't rectify. > What could work is this: > > (* Backport system calls to the kernel package.) > * Rebase the kernel headers package to the latest upstream version > (changing the UAPI headers used by glibc and applications). > (* Backport more system calls to the kernel package.) > * Rebuild glibc to generate SYS_ macro list. > (* Backport even more system calls to the kernel package.) > > This way, the glibc build would provide a full SYS_ macro list, > assuming that the kernel backporting does not overtake upstream (which > seems unlikely). However, some of the SYS_ macros will not work > because the distribution kernel will lake the correspondign __NR_ > macros. In which way does the macro not work? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."