From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59947 invoked by alias); 11 Feb 2020 07:47:07 -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 59939 invoked by uid 89); 11 Feb 2020 07:47:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Moreover, backported, up-to-date, uptodate X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581407224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QN95dG89NPal+IHjBdv7PIfXZcdRp+gYIzuTdJ20eN4=; b=ghJTGOTpsy3oPNiPvU5AAyyrI8vnf9Ad78rTpQCWw5lCLah5BtXUUyOyTCVzK2k5r61GD7 l8eUmrh7GO9UcFBYAMz1vh01ZaXPZe7+Kf1G0q6w6qIfhpW+9pEmjLmnP3zB2QXsEqJK4n 0abgmvEAZuxMQYGkm5BGXU4g1aiiq80= From: Florian Weimer To: Lukasz Majewski Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 00/26] Linux cleanups enabled by built-in system call tables References: <20200211002508.2df78b10@jawa> Date: Tue, 11 Feb 2020 07:47:00 -0000 In-Reply-To: <20200211002508.2df78b10@jawa> (Lukasz Majewski's message of "Tue, 11 Feb 2020 00:25:08 +0100") Message-ID: <87wo8tsh00.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-02/txt/msg00343.txt.bz2 * Lukasz Majewski: >> This series cleans up various quirks in the Linux implementation >> related to historic lack of system call numbers in several places. > > I'm wondering if those "system call tables" are generated from headers > from contemporary Linux (e.g. 5.5) or the oldest supported by glibc > (3.2)? We are keeping them up-to-date with the latest released kernel headers. > Moreover, I thought that the > > #ifdef __NR_foo_syscall__ define was to prevent from mismatch between > newest glibc build with old linux kernel headers and running under yet > another kernel. It is very common that new system call numbers are backported. This happens even in upstream stable kernel series. We expect that the glibc sources are written in such a way that the __NR_* #ifdefs only cover the availability of the number itself. They are not treated as a proxy for anything else (such as availability of types in headers or individual header files). I've posted a patch series that should clarify this: it removes historic #ifdefs which are no longer needed under the new model: > Is there any documentation regarding this new "approach"/"feature" with > those "system call tables"? I'm not sure what needs to be documented. Only two things should have changed: * It is no longer necessary to write these #ifdefs. * If one compiles glibc with older UAPI headers, you still get a full glibc with all features, as far is that possible. Previously, some parts could be stubbed out (e.g., return ENOSYS unconditionally even if the kernel supports the feature). Now, this only happens if Linux has not published required system call numbers. Thanks, Florian