tm(3): fix field name tm_isdt -> tm_isdst - #72
Open
ikolesnikes wants to merge 10000 commits into
Open
Conversation
Previously took ~2.5sec on my laptop, now 0.03sec. Previously took ~10sec on a wiiu, now ~0.5sec. Output is meant to be byte-for-byte identical, except possibly in cases that could have screwed up ctwm by quoting shenanigans which are now escaped. (I hope the escape sequences work, didn't actually check how ctwm interprets them.) Can maybe support Exec line with `"' in them by deleting some code (marked XXX) but I didn't test that it actually works that way. PR bin/59958: ctwm: long delay during ctwm_app_menu
should have done this closer to: https://mail-index.netbsd.org/source-changes/2026/01/19/msg160286.html
Note, this is not really a standards issue, POSIX says: If the -m option is specified, the number of characters shall replace the <bytes> field in this format. There is no output format in POSIX which permits both bytes and characters to be specified, and since which value represents which counter is determined entirely by position, which of bytes or characters would come first if both were to be presented would be indeterminate, so I won't be doing that. Slightly different wording used than that suggested bty Sebastian Ritter in the PR.
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.
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.
no functional changes
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.
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. dmesg with this fix: ``` [ 1.054235] apei0 at acpi0: ACPI Platform Error Interface [ 1.054235] apei0: BERT: OemId <HPQOEM,SLIC-WKS,00000001> AslId <INTL,00000001> [ 1.054235] apei0: BERT: 0x8000 bytes at 0x6bce6018 [ 1.054235] apei0: BERT: no boot errors recorded [ 1.054235] apei0: EINJ: OemId <HPQOEM,SLIC-WKS,00000001> AslId <INTL,00000001> [ 1.054235] apei0: EINJ: can inject: 0 [ 1.054235] apei0: ERST: OemId <HPQOEM,SLIC-WKS,00000001> AslId <INTL,00000001> [ 1.054235] apei0: ERST: 0 records in error log 8096 bytes @ 0x6bce4078 attr=0 [ 1.054235] apei0: HEST: OemId <HPQOEM,SLIC-WKS,00000001> AslId <INTL,00000001> [ 1.054235] apei0: HEST: 0 hardware error sources ```
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
blocking here can end up with a deadlock because ordinary vnops can wait for memory holding the range lock. fixes PR/60004 https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=60004
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 what makes ccd useful) the flags were not optional. Correct that, so that we move from: playground# ccdconfig ccd0 32 NAME=TST_SWAP_1 NAME=TST_SWAP_2 ccdconfig: invalid flags argument: NAME=TST_SWAP_1 to: playground# ccdconfig ccd4 64 NAME=TST_SWAP_3 NAME=TST_SWAP_4 NAME=TST_SWAP_5 playground# leading to: playground# ccdconfig -g ccd4 64 0x0 12884901888 /dev/dk14 /dev/dk15 /dev/dk16 ccd0 32 0x0 8589934592 /dev/dk12 /dev/dk13 The ccd0 config was done again (not shown) with the flags option supplied. Since no-one has ever cared about this, no pullups planned. (More changed to ccdconfig coming soon.)
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. Also add an option (-s), to output the flags as strings (only with -p, not -g), so humans don't need to remember which bit in the flags means what. Implement more human friendly names for the flags, and make them case independent (whoever would specify "CCDF_UNIFORM" when "2" would do, provided one remembers that 2 is the right value - now "uniform" can replace it). Use the friendly names in -s output. And also, since the config file (and command line) allows the NAME=wedge-label form of device specification, rather than /dev/dkN (almost always better, as the dkN numbers aren't always stable across reboots), add another option (-W, like df) to replace the device name in output (both -p and -g) with the appropriate NAME= string, when one exists. But as wedge labels can contain almost anything, also add another option (-w) which will ignore any wedge labels that contain characters which would confuse parsing (space, tab, or newline). To make it easier to have a preferred set of options to use, allow the (new) CCDCONFIG environment variable to specify any of these new options (and -v) - but not the "action" options (-c -C -u -U), which should always be specified on the command line. To allow this to work, add another few options to reverse the effects of -h -s -v -W (etc). There is a little more, including sorting the output from -g and -p when no ccd args are given (ie: all) so the output is generated in ccd unit number order, rather than in LIFO order, which was how it used to appear (most recently configured first). The man page (ccdconfig(8)) has been updated, minor changes also made to ccd.conf(5). One change of note there, all [ ] (meaning optional) around ellipses (meaning "previous may be repeated") removed, there is no need to say "the previous thing may optionally be optionally repeated". (The same change was applied to the usage message.) Since this is all "new feature" type stuff (the removal of the size from ccdconfig -g perhaps excepted), no pullups are planned, ccdconfig(8) says the new stuff was first added in NetBSD 12.0. Note that since this need not be frozen until -12 is actually released (and since -11 isn't out yet, that will be some time) any of the new stuff can be revised/changed/removed if it seems that something could be better, or is unnecessary, etc.
.Ar produces "file ..." so make "dev ..." here follow the same pattern using the right font too.
macppc/conf/POWERMAC_G5, like they are in macppc/conf/GENERIC. Discussed on port-macppc.
second and final part to fix PR#60025. XXX: pullup-*
This call was originally introduced in sys/arch/amd64/amd64/mem.c rev. 1.11 back in 2003 by fvdl@ with the commit message: > Proper checks for kmem reads beyond _end https://mail-index.netbsd.org/source-changes/2003/10/14/msg135803.html At some point, SOMEBODY added an assertion in uvm that made it stop working: > uvm_map(9): Sprinkle assertions and interface contract comments. > > No functional change intended. https://mail-index.netbsd.org/source-changes/2024/08/13/msg152763.html (Really, this assertion revealed that this path was broken all along.) This patch makes the amd64 mm_md_kernacc match the corresponding logic in uvm_kernacc around uvm_map_checkprot: 104 vm_map_lock_read(kernel_map); 105 rv = uvm_map_checkprot(kernel_map, saddr, eaddr, prot); 106 vm_map_unlock_read(kernel_map); https://nxr.netbsd.org/xref/src/sys/uvm/uvm_glue.c#92 Now, all of these checks in /dev/mem and company look like TOCTOU bogosity, because the answers are stale by the time we reach uiomove, which has to re-check any access anyway: 269 if (!md_kva) { 270 bool checked = false; 271 272 #ifdef __HAVE_MM_MD_KERNACC 273 /* MD check for the address. */ 274 error = mm_md_kernacc(addr, prot, &checked); 275 if (error) { 276 return error; 277 } 278 #endif 279 /* UVM check for the address (unless MD indicated to not). */ 280 if (!checked && !uvm_kernacc(addr, len, prot)) { 281 return EFAULT; 282 } 283 } 284 error = uiomove(addr, len, uio); https://nxr.netbsd.org/xref/src/sys/dev/mm.c?r=1.25#269 But we can address that in a separate change. PR kern/59955: kernel diagnostic assertion "rw_lock_held(&map->lock)" failed: file "/home/riastradh/netbsd/11/src/sys/uvm/uvm_map.c", line 1704
error: adding 'size_t' (aka 'unsigned long') to a string does not append
to the string [-Werror,-Wstring-plus-int]
note: use array indexing to silence this warning
- don't use the glyph cache - it doesn't buy us anything when drawing mono characters and it can't deal with WSATTR_HILIT - gffb_sync() before drawing characters - turns out we can overrun the command buffer with this, which leads to occasional lockups. No measurable loss of speed.
i had a system soft-hang with cc1plus waiting for memory, but there is enough memory free now, but when i tried to "bt/a <cc1plus addr>" i was getting an extremely large output (several megabytes before i killed simh). we fetch the argument count from a 32-bit space in the stack frame, but it's only the bottom byte that matters, the other bytes should always be zero for netbsd, as they're used by VMS. mask the high bytes of this value before consuming it. also, since we don't expect to see them, simply give up when we find a "callg" instruction. i did attempt to handle this, but since they should not be present, and seeing one would indicate that an unexpected stack write to that bit, handling it just leads to more faults as they vax_ap pointer does not point to valid memory and triggers crash (ie, back to db> prompt.)
Fixed the mistyped field name in the man page for struct tm. Was tm_isdt, should be tm_isdst.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixed the mistyped field name in the man page for struct tm. Was tm_isdt, should be tm_isdst.