bin/59861 fix ccdconfig -g (and much more)
This change is (roughly) based upon the patch provided in the PR by
ssszcmawo at gmail, but with many changes, and additions.
First, make ccdconfig -g not include the ccd size in its output.
It is supposed to produce the format defined for the config file,
so a ccd can be manually configured, and then the entry for it
added to /etc/ccd.conf later so it will be configured again at
each reboot. The size is computed based upon the devices,
it is not an input parameter, and hence does not belong in the output.
Nevertheless, being able to observe the size is useful for understanding
the ccd, so add a new -p option which does include the size in its output.
While here, add an option (-h) allow the size to be output in the form
generated by humanize_number(3) for better human comprehension.
[41 lines not shown]
Make the optional flags for ccdconfig truly optional.
The usage message, and the man page synopsis, has always
said:
usage: ccdconfig [-cv] ccd ileave [flags] dev [...]
(plus the other variants not material here). That is, the "flags"
can be omitted.
And they could, as implemented, but only when there are (not counting
the -c/-v options) exactly 3 args.
That is:
ccdconfig ccd0 32 dev
would work, with dev being the (sole) device, rather than treated
as flags. In any other case (like, more than one dev, which is
[23 lines not shown]
zfs: add zfs_range_lock_try
i plan to use this to fix pgdaemon deadlock issue. (PR/60004)
(thus i didn't bother to implement RL_READER.)
note: recent openzfs has a similar function. (zfs_rangelock_tryenter)
this commit ought to be reverted when/if we switch to it.
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=60004
apei_hest: fix a zero-sized kmem_zalloc issue
zero-sized kmem_zalloc is illigal.
this fixes a crash seen on HP Z4 G4.
when installing netbsd 10.1 on the machine, i had to
work this around by "userconf disable apei" and
```
userconf=disable apei*
```
in boot.cfg.
"acpidump -dt" on the machine said:
```
Error Source Count=0
```
under the "HEST:" section.
[13 lines not shown]
pchtemp: add a simple driver for intel pch thermal sensor
tested on PCI_PRODUCT_INTEL_2HS_THERM, which was found on HP Z4 G4.
although other variants look compatible, i have not actually tested them.
(no hardware)
dmesg:
```
[ 512.596379] pchtemp0 at pci0 dev 20 function 2: Intel PCH Temperature Sensor
```
envstat:
```
[pchtemp0]
pchtemp0 temperature: 41.500 degC
```
enable in kernel configs where amdtemp is enabled.
the man page is mostly copy-and-paste from amdtemp.4.
Added restrict to SYNOPSIS for strtok_r(), and fix broken example.
strtok_r() (and strtok() which already had it here) gained "restrict"
for their params in ISO C 99 (and then in Posix 2001).
The example code worked for the particular example given (the input
data actually used) but was hopelessly broken in general. As part
of that (but not the actual breakage), if something defines MAXTOKENS
then allow that many tokens, not one less ... add an extra slot for
the terminating NULL.
While here, update the STANDARDS section a little.
Added "restrict" to args in declaration of strtok_r()
The "restrict" was included in strtok_r() in C99 and POSIX Issue 6 (2001).
(The same time it was added to strtok()).
strtok_r() actually dates from Posix I5 (1995), not I6 (2001) as the
guard on its definition states, but after all this time, clearly no-one
cares about that.
t_fpclassify: Show the floating-point bits more carefully.
Use formatbits(&f) rather than formatbits(f). This serves two
purposes:
1. Type-checking.
Can't accidentally pass a double where a float is needed -- a bug
that previously appeared a few times in this code.
2. Reducing the chance that the data will pass through floating-point
load/store instructions on x87.
Floating-point load of binary32 (float) or binary64 (double)
converts to x87 80-bit extended precision format internally, which
preserves all floating-point _numbers_ and _infinities_ but has
the side effect of changing signalling NaN to quiet NaN (and
raising FE_INVALID). This means that signalling NaNs were getting
wrongly printed _as if_ they were quiet NaNs, which is frustrating
[4 lines not shown]
More cleanups and simplifications (more of the previous).
In particular, there is no need to say "using the swapctl(2)
system call", the SEE ALSO to that page should make that clear
enough to anyone who actually cares, which is not required of
a user of swapctl(8).
Minor other changes (a few grammar cleanups), and one new
BUGS entry added (should have been there for ages now).
swapctl(8): edit to g/c ornate verbosity
In a typical
-x The -x option is used to cause swapctl to frob.
description the relevant bits of information are 1) "-x" and 2)
"frob", so just make it say:
-x Frob.
The pleonastic repetitions just get in the way. The effect is
cumulative and by the second page it makes you want to bang your head
against the wall and not in a good way.
