From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        =?UTF-8?Q?Bastien_Roucari=C3=A8s?= <rouca@debian.org>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
In-reply-to: 
 <CA+hUKGJPrRow2aiUSK=aep5nyXUaB0gBoDJQKfyCsP=-ivfapg@mail.gmail.com>
References: <4496616.iHFcN1HehY@portable-bastien>
 <af84e934-4e9c-4380-95ee-8921dab1254b@iki.fi>
 <1156374.1730396928@sss.pgh.pa.us>
 <7ec1c65c-1a28-49a7-af43-f77c260a3df6@iki.fi>
 <1292593.1730399134@sss.pgh.pa.us>
 <CA+hUKGLRXq0-s0n2=dy_A5iY-Omg628osyJEJMjPQ=6m566UgA@mail.gmail.com>
 <707008.1732325995@sss.pgh.pa.us>
 <CA+hUKGJPrRow2aiUSK=aep5nyXUaB0gBoDJQKfyCsP=-ivfapg@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Sat, 23 Nov 2024 18:10:17 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <736755.1732341046.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 23 Nov 2024 00:50:46 -0500
Message-ID: <736756.1732341046@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/736756.1732341046%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> (Nerd sniped) No NetBSD here but think a 32 bit kernel should expose
> sysctl machdep.id_isar, which should be an array of 6 ints, and bits
> 16-19 of id_isar[5] should give you the answer:

Huh.  cpuctl's arm32 module knows of machdep.id_isar, but it does not
appear to know that that word exists:

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/cpuctl/arch/arm.c?rev=3D1=
.6;content-type=3Dtext%2Fplain

But that developer.arm.com page seems pretty definitive.  Tomorrow
I'll have a go at spinning up a 32-bit NetBSD installation and test
it.  Thanks for the research!

> Since you included <aarch64/armreg.h>, and only care about non-zero,
> couldn't you use the mask from the header, instead of all that
> bitswizzling?

> return (id->ac_aa64isar0 & ID_AA64ISAR0_EL1_CRC32) !=3D 0;

I didn't actually look into that header ;-) ... I was just basing this
on what cpuctl's code does.  That version does look cleaner, at
least for aarch64 --- but given that the field is defined to be
in the same place in the relevant register for each arch, I'm
a bit inclined to keep the bit-swizzling and just have two paths
for getting the register contents.  Unless maybe that header is
also installed in arm32 builds, in which case we could do it as
you show for both arches.  I'll find out ma=C3=B1ana.

			regards, tom lane