Two issues:
- Always include vmparams.h via <machine/vmparams.h>, because redirection
logic elsewhere relies on this.
- But akshually, isn't not even needed here because the code that would
use it is #if 0'd out anyway.
So, collect the garbage and ramble on.
Pull up following revision(s) (requested by martin in ticket #275):
share/mk/bsd.own.mk: 1.1481 via patch
PR 58762: disable MKCOMPAT for earm*.
If someone is interested in re-adding support for oabi compat library
builds, they can figure out the missing bits. But for now, stop producing
bogus compat32/debug32 sets on all evbarm builds.
Pull up following revision(s) (requested by martin in ticket #274):
usr.bin/cksum/cksum.c: 1.53
PR 60154: do not print arbitrary control characters when printing
file names while checking hashes with the -c option.
Remove the upper bound on nkmempages for virt68k, else the kmem arena
gets easily starved on VMs with large memory configs (which is sort of
the whole point of virt68k).
Partially revert previous to fix the builds.
The UVM stats functions are used (apparently) by the RUMP
"kernel", and need to be exposed as they were before, so
for now, do that.
Feel free to undo this, and fix the problem some other way.
Reduce the pmap API surface exposed to modules. Of the ones that remain,
you could argue that those shouldn't be exposed either, but our file
system <-> pager interface is not that great, among other things, so
they have to remain for now.
arcbios: enable FPU around ARCS calls
This seems required for the SGI O2 for PROM graphics console IO to work
when it scrolls. See PR port-sgimips/60204 for more details.
The issue was introduced in v1.214 of sys/arch/mips/mips/locore.S .
Notably maya@ disabled the FPU early in boot, expecting the rest of
boot to run with the FPU disabled. The FPU is being explicitly
enabled/disabled here to keep to the spirit of maya@'s above commit.
A "better" solution would be to use the pcu API and mark the thread
as needing the FPU for the duration of the arcbios call, however:
* The current MIPS pcu FPU code in sys/arch/mips/mips/mips_fpu.c
doesn't support FPU use in kernel yet; and
* this stuff is called super early during boot and once the OS starts
the ARCBIOS API is no longer supposed to be used.
call this bozohttpd 20260503, and update the CHANGES for the last 2 years
o fix the default minimum TLS version to 1.1 from 1.3. the
manual already said 1.1 was the default. fixes PR#58878.
o log the correct port with TLS connections. fixes PR#59644.
o fix use-after-free, double-free, and bounds checking problems.
from shm.
o better lint support.
o several updates for the manual. from lukem.
add D Bohdan to the contributors list.
Hide platform vmparam differences away from user-space and modules.
For modules that need to know USRSTACK (exec / compat modules), provide
a way to get that via a variable initialized in cpu_startup().
Undo some of the previous, restore flexibility
This is related to PR bin/59957 (in that it is a continuation/
alteration of the previous fix). This was primarily designed
to (hopefully) fix the ~80 extra ATF test failures that the previous
solution caused, by allowing the utilities to work as they had
previously, rather than attempting to enforce one universal true
world order.
Change the openspecial() function to be findspecial() as it no longer
opens anything - but leave it in openspecial.c for several reasons:
First, it might make sense to recreate openspecial() for use in just
those utilities that want to do all that it did (just 2 of the four
that were modified to use it).
Also, this function (or functions) really should be moved to libutil,
rather than buried in sbin/fsck (which doesn't even use it/them at all
- though could perhaps use the findspecial() variant), and I didn't see
[27 lines not shown]
Despite pooka's dislike of the situation, it is sometimes unavoidable
that systems within a given $MACHINE may have different vmparams.
Furthermore, rump is fundamentally a user-space entity on NetBSD, and
it's absolutely true that different $MACHINEs within a $MACHINE_ARCH
may legitimately have different vmparams related to physical memory
layout, and so using the real <machine/vmparams.h> is an impediment
to a $MACHINE_ARCH-generic user-space build.
As such, rump once again has its own vmparams.h file with values that
should be perfectly adequate for the rump virtual environment and its
non-existent subordinate user-space.
