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 |
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 |