From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 504C0C77B7E for ; Tue, 2 May 2023 05:50:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233525AbjEBFsR (ORCPT ); Tue, 2 May 2023 01:48:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233294AbjEBFsP (ORCPT ); Tue, 2 May 2023 01:48:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDE6A19B7 for ; Mon, 1 May 2023 22:48:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 79EE36188A for ; Tue, 2 May 2023 05:48:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87E96C433A1; Tue, 2 May 2023 05:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683006492; bh=QFgaj7LjOrwpefjycjAmRiPltPmbzaKTfT0CxHr+JHM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hfa//+lu0sjGGGOxJsmQ44lujZhVUV+VfiLQUr0aH/LzssxPSs2lOuCQt22bq5KvA Wd+Y8u5Apo4fAjESUe3gn7M49eiSL8pt6WCiAitd7kUMepo2bUEsdbhdV7J6az9z7n I4LP9FNdulOHXU3bJqm5xUJhFQB+e8aFqAzD+0F3REly8K+dod9oBXxU3eVIfgYqh3 76np80FnIzeGF7TmEt7vw+0BPCnRB8z70XaLzMVW15BekKWUOdjb6NZxrhDIFwAu0v p9qVVUBSc7TP6ffTQgWhCuoXxcH9ZqIzDGavMrYmeDb/GJviWwFQ564PsBSDWtEofD JABXIA36Kf2oQ== From: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= To: Jessica Clarke Cc: Heiko Stuebner , Palmer Dabbelt , linux-riscv , Paul Walmsley , Kito Cheng , Conor Dooley , matthias.bgg@gmail.com, Heinrich Schuchardt , Greentime Hu , nick.knight@sifive.com, christoph.muellner@vrull.eu, philipp.tomsich@vrull.eu, richard.henderson@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org, Heiko Stuebner Subject: Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector In-Reply-To: <7DD2C38C-CBB3-41EE-A195-50E4C2451B7E@jrtc27.com> References: <20230424194911.264850-1-heiko.stuebner@vrull.eu> <87ednz7roh.fsf@all.your.base.are.belong.to.us> <7DD2C38C-CBB3-41EE-A195-50E4C2451B7E@jrtc27.com> Date: Tue, 02 May 2023 07:48:10 +0200 Message-ID: <878re77085.fsf@all.your.base.are.belong.to.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jessica Clarke writes: > All I wanted was some simple extension string -> version number function > as a standardised userspace interface... because at the end of the day > people just want to know =E2=80=9Ccan I use extension Y?=E2=80=9D, possib= ly with a > minimum version. But maybe there=E2=80=99s some hope that Linux libcs will > translate such queries into poking at this hwprobe thing. Using hwprobe to plumb such an interface for, say libcs, was what I was envisioning. > Though god knows what they=E2=80=99re going to do about vendor extensions, > especially if those vendor extensions only get supported in vendor > forks of the kernel (who=E2=80=99s allocating their encodings? Xvendorfoo > exists to namespace them and give vendors control...). "they're"? I'm sure your input on how to design such an interface would be be much appreciated! My view is that the "design upfront" strategy here hasn't really worked out, so the hwprobe approach is to start small, and extend when there's need. Hopefully, there will be fewer pains with this approach. That's why I was very surprised to see this series, which introduces Yet Another Interface. Bj=C3=B6rn