This update makes this driver more than just an example and allows for:
o More than one pin to be attached to a gpioirq instance. That is,
the mask parameter can be greater than 0x01 now.
o A /dev/gpioirqN device that allows GPIO pin interrupts to be
transported into userland. This is a device that can be opened for
reading with a simple fixed output indicating the device unit, pin
number and current pin state.
This update was used as part of a physical intrusion detection system
where multiple switches (i.e. window magnetic reed switches and etc.)
are tied to a bunch of GPIO inputs with userland software that reacts
to the pins changing state.
viocon* at virtio?
/dev/ttyVI??
Tested under qemu with:
qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...
I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.
(Criterion (c) excluded sparc and sparc64.)
Now that we have WSDISPLAYIO_LISTFONTS we want users to be able to use it.
NB: older kernels didn't check that WSDISPLAYIO_LDFONT was performed
on wsfont(4) device opened for writing and relied on its restrictive
root-only permissions to restrict who can load fonts.
Driver module as illustrated here:
https://www.sparkfun.com/products/13911
A SCMD module is a ARM SOC simular to a Arduino in front of a motor
driver chip. The single SCMD module can control two motors and up to
16 additional modules can be chained together using an internal I2C
bus. One can interface with the SCMD using tty uart commands, SPI or
I2C. The driver in this commit adds a kernel driver for the I2C and
SPI interfaces. The command line utility provides a set of
convenience commands that support most of the functions of the SCMD
and is able to use the tty uart mode, SPI user land or the included
kernel driver in a uniform manor.
The use of the SCMD module is mostly for small robots and the like,
but it can control anything that is controllable by voltage.
sensor such as:
https://www.adafruit.com/product/2857
This is a higher priced sensor with a lot of features, including the
ability to do sub-second periodic updates. The driver supports
everything about the sensor except for the alert pin.
Introduce a /dev/efi character device that provides a means for accessing
UEFI RT variable services from userland. Compatible with the FreeBSD ioctl
interface for ease of porting their libefivar and associated tools.
The ioctl interface is defined in sys/efiio.h.
To enable support for this on an arch, the kernel needs `pseudo-device efi`
and the MD EFI implementation needs to register its backend by calling
efi_ops_register(). This commit includes an implementation for Arm.
This exists for compatibility with a Linux interface which was apparently
deprecated in Linux 2.6. There are various mailing list threads going
back to 2004 where the usefulness of this driver is discussed, but
the conclusion is that scanner software has all moved to using ugen(4)
instead, and enabling this driver will not help you scan things.
The /dev/acpi character device gives an aperture into physical memory
that allows only read access to known ACPI tables: RSDP, XSDT/RSDT, and
the root tables. Adapt acpidump(8) to use this interface by default,
falling back to the old /dev/mem method if it is not available or if
ACPIDUMP_USE_DEVMEM=1 is set in the environment. The user visible benefit
of this change is that "options INSECURE" is no longer required to
dump ACPI tables.
At this point it is highly unlikely this 1999 device still has users,
but it still comes up in the context of maxv's USB-fuzzing (and any device
could pretend to be a urio(4)), so it's best to get rid of it.
Renamed all major entries to obsolete, as was done in previous removals.
This still requires an update to sanitizers, but they're located in
"external", perhaps it should be first committed upstream?
Proposed on tech-kern a month ago.
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/01/13/msg025938.html
This was never (intentionally) enabled by default, and the design has
some shortcomings. You can get mostly the same results with ktrace,
as in usr.bin/make/filemon/filemon_ktrace.c which is now used instead
of filemon for make's meta mode.
If applications require higher performance than ktrace, or nesting
that ktrace doesn't support, we might consider adding something back
into the vfs system calls themselves, without hijacking the syscall
table. (Might want a more reliable output format too, e.g. one that
can handle newlines in file names.)
from userland via /dev/vhci. Using this, it becomes possible to test and
fuzz the USB stack and all the USB drivers without having the associated
hardware.
The vHCI device has four ports independently addressable.
For each xfer on each port, we create two packets: a setup packet (which
indicates mostly the type of request) and a data packet (which contains
the raw data). These packets are processed by read and write operations
on /dev/vhci: userland poll-reads it to fetch usb_device_request_t
structures, and dispatches the requests depending on bRequest and
bmRequestType.
A few ioctls are available:
VHCI_IOC_GET_INFO - Get the current status
VHCI_IOC_SET_PORT - Choose a vHCI port
VHCI_IOC_USB_ATTACH - Attach a USB device on the current port
VHCI_IOC_USB_DETACH - Detach the USB device on the current port
vHCI has already allowed me to automatically find several bugs in the USB
stack and its drivers.
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.
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.
provides support for hardware-accelerated virtualization on NetBSD.
It is made of an MI frontend, to which MD backends can be plugged. One
MD backend is implemented, x86-SVM, for x86 AMD CPUs.
We install
/usr/include/dev/nvmm/nvmm.h
/usr/include/dev/nvmm/nvmm_ioctl.h
/usr/include/dev/nvmm/{arch}/nvmm_{arch}.h
And the kernel module. For now, the only architecture where we do that
is amd64 (arch=x86).
NVMM is not enabled by default in amd64-GENERIC, but is instead easily
modloadable.
Sent to tech-kern@ a month ago. Validated with kASan, and optimized
with tprof.
is of poor quality, and is now an obstacle to MP-ification. It was removed
ten years ago from FreeBSD for the same reason.
This retires a big user of the mbuf API, and will ease maintenance of the
kernel.
node results in a non working config, despite following manual to get setup.
Remove a step for the user by creating a device node for veriexec by default.
ok mrg jakllsch
brad