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.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,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 C58D41F453 for ; Wed, 30 Jan 2019 21:10:18 +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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=eazQI JJJoAqfXJFaWoP/KOMq5k0lW5s5zKw1onmB1SlGyS8jb4/buXPcrR8SCj0r/8+MU EFa1t1c8llP5acyrZULSRCuUgB5WzgPbqH+ytaDdG6BhDKmTaqywGJScnKqlK2Z2 VAGDyTHIEDbZ8pW54kDNlaGmJwht+OHTe8vfls= 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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=KZ/D6QMNm7f BitjafHshM6HR8lo=; b=tWXID8TzpOx8TG799OOJLx6I6cnWqdOzX0G+cKp1KL0 vgmiBwRnqYzSizUKvjGX74KZyRGoqTa/qkOMxFE8Zsj02kAnbjr6dJd9oJRKeQLK 6sb/U77tYt6Ic1/Jl6b/rSuqnHw44eO8S2xIIVqWzDWWQARXiUuJeIK9338Hn4vU = Received: (qmail 77504 invoked by alias); 30 Jan 2019 21:10:16 -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 77464 invoked by uid 89); 30 Jan 2019 21:10:16 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Wed, 30 Jan 2019 21:10:07 +0000 From: Joseph Myers To: Mathieu Desnoyers CC: carlos , Florian Weimer , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6) In-Reply-To: <1832200535.4162.1548871426959.JavaMail.zimbra@efficios.com> Message-ID: References: <20190121213530.23803-1-mathieu.desnoyers@efficios.com> <632671842.3079.1548781059601.JavaMail.zimbra@efficios.com> <596949707.3888.1548812359874.JavaMail.zimbra@efficios.com> <1832200535.4162.1548871426959.JavaMail.zimbra@efficios.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Wed, 30 Jan 2019, Mathieu Desnoyers wrote: > #if defined (__NR_rseq) && !defined (RSEQ_SIG) > # error "UAPI headers support rseq system call, but glibc does not define RSEQ_SIG." > #endif > > Would that take care of your concerns ? That would of course need appropriate conditionals based on the most recent kernel version for which a given glibc version has been updated, so that using new kernel headers with an existing glibc release does not make the build fail (cf. the test of syscall-names.list). And being able to write such a test only solves one half of the problem - it needs to be easy to determine what value to put in that header in glibc for an architecture that's newly gained support in the kernel, *without* needing any architecture expertise. -- Joseph S. Myers joseph@codesourcery.com