From: Segher Boessenkool <segher@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org,
Paul E Murphy <murphyp@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH Linux] powerpc: add documentation for HWCAPs
Date: Tue, 24 May 2022 12:38:14 -0500 [thread overview]
Message-ID: <20220524173814.GH25951@gate.crashing.org> (raw)
In-Reply-To: <20220524093828.505575-1-npiggin@gmail.com>
Hi!
On Tue, May 24, 2022 at 07:38:28PM +1000, Nicholas Piggin wrote:
> Thanks for all the comments and corrections. It should be nearing the
> point where it is useful now. Yes I do think it would be useful to align
> this more with OpenPOWER docs (and possibly eventually move it into the
> ABI, given that's the allocator of these numbers) but that's not
> done yet.
The auxiliary vector is a Linux/glibc thing, it should not be described
in more generic ABI documents. It is fine where you have it now afaics.
> +Where software relies on a feature described by a HWCAP, it should check the
> +relevant HWCAP flag to verify that the feature is present before attempting to
> +make use of the feature.
> +
> +Features should not be probed through other means. When a feature is not
> +available, attempting to use it may result in unpredictable behaviour, and
> +may not be guaranteed to result in any reliable indication that the feature
> +is unavailable.
Traditionally VMX was tested for by simply executing an instruction and
catching SIGILL. This is portable even. This has worked fine for over
two decades, it's a bit weird to declare this a forbidden practice
now :-)
It certainly isn't recommended for more complex and/or newer things.
> +verstions.
(typo. spellcheck maybe?)
Segher
next prev parent reply other threads:[~2022-05-24 17:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 9:38 [PATCH Linux] powerpc: add documentation for HWCAPs Nicholas Piggin
2022-05-24 9:52 ` Florian Weimer
2022-05-24 18:32 ` Segher Boessenkool
2022-07-15 1:17 ` Nicholas Piggin
2022-07-15 14:35 ` Segher Boessenkool
2022-05-24 17:38 ` Segher Boessenkool [this message]
2022-07-15 1:00 ` Nicholas Piggin
2023-06-06 14:49 ` Passing the complex args in the GPR's Umesh Kalappa
2023-06-06 14:58 ` Andrew Pinski
2023-06-06 15:05 ` Umesh Kalappa
2023-06-06 15:16 ` Andrew Pinski
2023-06-06 16:42 ` Segher Boessenkool
2023-06-06 17:07 ` Umesh Kalappa
2023-06-06 17:33 ` David Edelsohn
2023-06-07 13:17 ` Michael Matz
2023-06-06 17:18 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220524173814.GH25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=murphyp@linux.ibm.com \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.