My keyboard and mouse use multiple device nodes each. I can't use
any other devices once they're attached. With my keyboard, mouse,
and two game controllers attached, a total of 9 nodes are required.
Particularly, high-end keyboards with N-key rollover support require
more device nodes, since they pretend to be multiple keyboards to work
around limitations in the uhid compat spec.
My original intention was to raise it from 4 to 12, but martin
suggested increasing it to 16.
"somewhat insane, but so is reality" - mlelstv
(like sensor readout) are locked, so that a userland program may interfere with
envsys operation.
To use this you need a program like ipmitool built with OpenIPMI support.
pipes. Skip the "error" printf from GetSmtId() as there is no easy
portable way to avoid it occurring (there are complicated ways) - but
we don't need it, there is no logical difference between "error" and ""
so just use the latter (if we get an ID, good, if there is nothing, then
there is none - saying 'error' does not mean anything.)
Use quoting everywhere possibly useful (always the right way, except
in the few cases where it is wrong...)
Avoid using cut & grep (from /usr/bin) so script could run before /usr
is mounted (pity cpuctl is in /usr/sbin ...).
Use sysctl -n rather than attempting to parse its output.
parses the output of cpuctl, and executes "cpuctl offline" for each CPU
that has SmtID!=0.
The default is "smtoff=NO", which means that SMT remains enabled.
boards that use u-boot. A known board database lists boards and their
respective u-boot packages. u-boot packages are discovered at run-time
(in /usr/pkg/share/u-boot, by default). These packages contain board
database overlays that describe u-boot installation procedure that's
specific for that board.
Support this as a native tool and as a host tool. The native tool
will attempt to determine the running board type using OpenFirmware
calls. Host tool and native tool alike may also specify a board type
directly using the "-o board=xxx option" or have installboot(8) determine
the board type from a device tree blob using "-o dtb=/path/to/board.dtb".
A "-o media=xxx" option is provided for boards that have different u-boot
binaries and/or installation procedures for different media types (e.g.
SDMMC, eMMC, or USB).
This is trivial to extend to other evb* platforms that use u-boot, even if
they don't use FDT for autoconfiguration.
enabled and don't warn our users that it might not and already suggest
workarounds.
The ability to disable ACPI and SMP is still there, by dropping to
the boot prompt.
for x86 and evbarm:
- install headers and libEGL
- install xorg-server glamoregl component
- link xorg drivers against gbm/egl
bonus fix:
- fix some wrongly marked compatx11file files
build tested on shark, sgimips, evbarm64-el, amd64 and i386.
run tested on radeon, intel and nvidia on amd64, including
'modesetting' driver on amd64. however, my systems disable
it due to llvmpipe so i'm not sure what is happening.
./usr/include/$MACHINE and automatically add it.
add sun68k for sun2/sun3. tested on about 12 platforms.
there may be more failures to figure out but this should make
them all special cases rather than always expected cases.
fortunately, most builds don't see to hit these issues for
reasons i haven't determined yet.
- add khrplatform.h for mesa_ver=18 platforms.
need to enable libvdpau.pc generation (needs special rules)
this mostly comes from maya in the first one, and a small part
of the second:
commit 48eb746983a5a7967fba221e7b167808af36f44a
Author: Maya Rashish <maya@NetBSD.org>
Date: Sun Feb 24 09:31:22 2019 +0200
More of vdpau. Cogs spin.
commit d9fbba8f61a43648d32f160c5fa62626788566ff
Author: Maya Rashish <maya@NetBSD.org>
Date: Sat Feb 23 22:36:37 2019 +0200
Adjust for MesaLib 18.
Build llvmpipe driver on x86 (the driver itself is x86-only).
build llvm on all x86, even on GCC builds.
galahad driver removed (upstream).
Don't build mesa 7 at all.
(how many more builds will i find like this? the end result
is that i think we should generate the ./usr/include/$MACHINE
entry, i think, but i have to survey many ports.)
Previously spi would configure the controller to use the lowest speed of
all connected devices since the kernel started and to fail attempted mode
changes. This is now improved to keep individual modes and speeds for each
slave and to reconfigure the controller as necessary for each transfer.
Added man page for spi(9).
The KCOV driver implements collection of code coverage inside the kernel.
It can be enabled on a per process basis from userland, allowing the kernel
program counter to be collected during syscalls triggered by the same
process.
The device is oriented towards kernel fuzzers, in particular syzkaller.
Currently the only supported coverage type is -fsanitize-coverage=trace-pc.
The KCOV driver was initially developed in Linux. A driver based on the
same concept was then implemented in FreeBSD and OpenBSD.
Documentation is borrowed from OpenBSD and ATF tests from FreeBSD.
This patch has been prepared by Siddharth Muralee, improved by <maxv>
and polished by myself before importing into the mainline tree.
All ATF tests pass.
put compat stuff in NetBSD.compat.$MACHINE_ARCH, and normal
stuff in NetBSD.dist.$MACHINE/MACHINE_ARCH, etc.
probably need at at more files for sh3, mips, ppc, sparc,
m68k, arm, ia64, etc., as every port has port- or arch-
specific header subdirectory.
thorpej