From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-95366-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 112827 invoked by alias); 17 Aug 2018 15:46:06 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 112560 invoked by uid 89); 17 Aug 2018 15:45:55 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:875
X-HELO: mail-oi0-f48.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=r2zEmb1wfenAPrxcpVICCigoGEd4SpTmudac1Ci2iG4=;
        b=fd1VirZW+DI4r1S4WAGlFLEi6IGYbrNWBUMBovMopzRinYkhTor5Yn/aeQ/AXKKkMR
         ZeHOtLP/BoWWav4bfQ8j9QTkHmF5EtFu+eFxawG896/YgO0zkFMED4UDwVYgU6F52YrC
         JP1719eJ80hJNBf8bXnkoZuJTH2Tutv2gfazLdt/tovz/VkcuxRC1UKlA2Fi6ETT3D6f
         NpwZEIC1wOi8skr2vGm6P0bOO31RLmZJNRXFyCzZdyBNV/2NS/Gf+1aND+7mrH9Zlp15
         6nsowo/eC+40QYK00aKZ4LHU5jtTo/QiEh+EN97X+MSJeV7ySC0tbY0fxIE0HVEK1mNc
         p91Q==
MIME-Version: 1.0
In-Reply-To: <ffb5c746-1672-076c-e1e2-ae6c4f435026@redhat.com>
References: <20180729161623.GA17944@gmail.com> <ffb5c746-1672-076c-e1e2-ae6c4f435026@redhat.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 17 Aug 2018 15:46:00 -0000
Message-ID: <CAMe9rOoMsLTXcpvGLnaeDZ4PiOu3WHVkU+STO4pBnK1VDcYq9g@mail.gmail.com>
Subject: Re: RFC: Add <sys/platform/x86.h> to glibc 2.29
To: Florian Weimer <fweimer@redhat.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-SW-Source: 2018-08/txt/msg00397.txt.bz2

On Fri, Aug 17, 2018 at 7:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 07/29/2018 06:16 PM, H.J. Lu wrote:
>>
>> extern enum cpu_features_kind __x86_get_cpu_kind (void)
>>       __attribute__ ((const));
>>
>> extern const struct cpuid_registers *__x86_get_cpuid_registers
>>       (unsigned int) __attribute__ ((const));
>>
>> extern unsigned int __x86_get_arch_feature (unsigned int)
>>       __attribute__ ((const));
>
>
> Are these functions supposed to be usable in IFUNC resolvers?

They have the same limitation as

/* Used from outside of glibc to get access to the CPU features
   structure.  */
extern const struct cpu_features *__get_cpu_features (void)
     __attribute__ ((const));

> Shouldn't these identifiers be in the public (non-internal) namespace?
>

Do we have precedents for such arch specific public functions?

-- 
H.J.