From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bastien Roucariès <rouca(at)debian(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Detection of hadware feature => please do not use signal |
Date: | 2024-11-23 05:50:46 |
Message-ID: | 736756.1732341046@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thomas Munro <thomas(dot)munro(at)gmail(dot)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=1.6;content-type=text%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) != 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ñana.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-11-23 08:37:18 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
Previous Message | Thomas Munro | 2024-11-23 05:10:17 | Re: Detection of hadware feature => please do not use signal |