Re: Detection of hadware feature => please do not use signal

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 01:39:55
Message-ID: 707008.1732325995@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:
> Unfortunately it looks like NetBSD doesn't put AT_HWCAP into its
> auxv[], or even expose it to user space nicely, and those libraries
> don't seem to know of another way. Hopefully NetBSD will align with
> those other systems for portability's sake. The only other way I
> could find in a quick googling session is /usr/sbin/cpuctl, root only,
> no cigar (but a solid clue that the information is floating around
> somewhere, it just depends where exactly the root-only fencing is
> happening).

I poked into this with NetBSD and found that cpuctl's "identify"
option works just fine without root. So that motivated me to dig
into its source code, and I end up with the attached. Sadly it only
works in 64-bit; there is presumably a way to detect this in 32-bit
as well, but cpuctl doesn't know it. That doesn't bother me a whole
lot though, at least not nearly as much as the 64-bit case. Anybody
running PG on 32-bit ARM shouldn't be expecting great performance.

I've checked this on NetBSD 9.2 and 10.0. I don't have hardware
that should return false (and there may not be any such 64-bit
hardware anyway...), so there's not much more I can test.

regards, tom lane

Attachment Content-Type Size
netbsd-arm-crc-detection.patch text/x-diff 1.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-11-23 03:45:49 BUG #18721: Documentation for psql does not specify that the history feature doesn't work
Previous Message Nathan Bossart 2024-11-22 20:17:07 Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails