PR/59957: Taylor R. Campbell: Centralize the disk open sequence from newfs
and tunefs to a new function "openspecial" and use it to fix this PR, and
the same issue with newfs_ext2fs.
Import zstd-1.5.7 (previous was 1.5.6)
V1.5.7 (Feb 2025)
fix: compression bug in 32-bit mode associated with long-lasting sessions
api: new method `ZSTD_compressSequencesAndLiterals()` (#4217, #4232)
api: `ZSTD_getFrameHeader()` works on skippable frames (#4228)
perf: substantial compression speed improvements (up to +30%) on small data, by @TocarIP (#4144) and @cyan4973 (#4165)
perf: improved compression speed (~+5%) for dictionary compression at low levels (#4170)
perf: much faster speed for `--patch-from` at high compression levels (#4276)
perf: higher `--patch-from` compression ratios, notably at high levels (#4288)
perf: better speed for binaries on Windows (@pps83) and when compiled with Visual Studio (@MessyHack)
perf: slight compression ratio improvement thanks to better block boundaries (#4136, #4176, #4178)
perf: slight compression ratio improvement for `dfast`, aka levels 3 and 4 (#4171)
perf: runtime bmi2 detection enabled on x86 32-bit mode (#4251)
cli: multi-threading as default CLI setting, by @daniellerozenblit
cli: new `--max` command (#4290)
build: improve `msbuild` version autodetection, support VS2022, by @ManuelBlanc
build: fix `meson` build by @artem and @Victor-C-Zhang, and on Windows by @bgilbert
build: compatibility with Apple Framework, by @Treata11
[8 lines not shown]
PR lib/60219 -- Fix sysconf(_SC_TZNAME_MAX)
That value is supposed to be the minimum value allowed for
the maximum length of a timezone abbreviation. It cannot
be something larger than is allowed for that (and NAME_MAX
has nothing to do with it)
It defines the max lengths allowed for the words in
TZ=Frankenstein-7Monster-6[transition rules]
in old style POSIX TZ variable settings - the POSIX required
minimum value is 6 (so "Frankenstein" would not fit in a minimalist
POSIX implementation).
For now, sync the values between libc/sysctl() and libc/localtime()
via a new _TZNAME_MAXIMUM definition in <time.h> and use that for
both purposes (as a possible default anyway for localtime() - there
the default value used will always be at least 254, and building with
[8 lines not shown]
nvmm: Don't report physical lapic freq as virtual lapic freq.
The virtual lapic emulated by qemu in software always ticks at 1 GHz,
but the physical lapic on my laptop, for example, ticks at 24 MHz.
In order for this to work as iMil intended, we need some way for the
hypervisor (such as qemu) to tell nvmm what its lapic frequency is.
Until we have that, we can't correctly report any alleged lapic
frequency to the guest.
PR kern/59424: hardclock ticks run at breakneck pace under qemu
t_sha512trunc.c: add some more test cases
These were randomly selected (biased for size) from the same source as
the original ones. If still more are needed, reading from an input file
would be the better (or, size-wise only) option, but this is simpler
as-is.
t_sha512trunc.c: fix test case iteration
The code in check() was repeatedly running the first element of the array
of test cases, rather than iterating. (Noted by human-powered code
inspection while preparing another commit that will follow shortly.)
Provide defaults for VM_PHYSSEG_MAX, VM_PHYSSEG_STRAT (single segment),
VM_NFREELIST, and VM_FREELIST_DEFAULT (single freelist).
Achievement unlocked: some platform <machine/vmparam.h> files are now just
simple wrappers around <m68k/vmparam.h> (and a few more are *very* close).
Centralize the definition of VM_PHYS_SIZE. While doing so, change
the logic for its value, eliminating the obsolete USRIOSIZE constant.
Previously, on Utah-derived platforms, USRIOSIZE was defined as the
number of PTEs used for phys_map, and VM_PHYS_SIZE was USRIOSIZE * PAGE_SIZE.
The USRIOSIZE was in turn derived from NPTEPG (number of PTEs in one page).
On 4K page systems, that was a 4MB phys_map. On 8K page systems, that
was a 16MB phys_map (4x muliplier comes from 2x PTEs per page, 2x bytes
per page mapped). These values are totally excessive; the most pressure
phys_map experiences on a typical system is boot-time fsck, and the max
mapping request it will see is MAXPHYS (64KB); it is generally not used in
steady-state operation. In contrast, alpha's phys_map is 512KB and 32-bit
x86 is ~1MB.
Instead, simply define reasonable values for VM_PHYS_SIZE independent of
PAGE_SIZE: 256KB for 68010, 1MB for everone else. Per-platform constraints
can override these values (although they happen to match what Sun2 and Sun3
use, respectively).
[3 lines not shown]
Enable __USE_TOPDOWN_VM; this was set on sun2 and sun3, but somehow
forgotten on the rest of m68k. (Seriously, why is this even optional?)
Tested on both Utah and new pmap.
x68k: Initialize d_bbsize and d_sbsize on the disklabel always.
These values are for (old) FFS, so it didn't make sense to initialize
only when the BSD disklabel was missing and the Human68k partition existed.
This avoids disklabel(8)'s warnings:
disklabel: boot block size 0
disklabel: super block size 0
Inspired from PR install/59600.
sysinst/x68k: Remove unnecessary conditions in md_disklabe_is_default().
lp->d_bbsize and lp->d_sbsize should be constants (this is probably another
bug) and should not be part of this check.
Fix PR install/59600
Should be pulled up -10 and -11.
