portion of a Tigard debug board and changes the permissions of the
appropriate /dev/ugenN.* nodes to allow access without superuser
permissions, suitable for using e.g. openocd with the device.
This example can be easily modified to support other generic USB devices
that have user-space drivers where running as the superuser is not desired.
for USB serial interfaces, regardless of where the interface is connected
or the order of enumeration. This requires the USB device to have a
"serialnumber" to function. Examples:
- uftdi serial adapter with two ports:
/dev/tty-uftdi-FT64S4YP-1 -> /dev/ttyU0
/dev/tty-uftdi-FT64S4YP-2 -> /dev/ttyU1
- uslsa serial adapter:
/dev/tty-uslsa-01E7ABCC -> /dev/ttyU4
This allows something like the following in /etc/remote:
sun3:dv=/dev/tty-uftdi-FT64S4YP-1:br#9600:pa=none:dc:
That path will always be stable regardless of which /dev/ttyU* node is
actually assigned when the serial adapter is plugged in.
For now it is wired up only in x86 ALL kernels, and built as a module
for x86 and Arm. Once it gets a little more testing on machines with
APEI, I would like to flip it on by default.
PR kern/58046
Maybe this should also be wired up to `release' to put the ramdisk in
the releasedir so we detect destdir path leakage like this had.
PR port-evbarm/58035
The functions snprintb and snprintb_m are specific to NetBSD, and their
format strings are tricky to get correct. Provide some assistance in
catching the most common mistakes.
It looks required only on building Xorg server binary and
unnecessary for release (actually marked as obsolete only on vax),
but no simple settings to "build static libraries without installation"
and most ports will be switched to Xorg 1.20 soon.
/var/run is emptied at boot time by /etc/rc.d/mountcritlocal, so
there's no point in creating this at install time -- it has to be
created on the fly after /var/run is cleared on every boot anyway.
Mark /var/run/named obsolete in the set lists. XXX This isn't quite
right, because it is legitimate for /var/run/named to exist in a
running installation, but it doesn't exist in a freshly installed
system any more. Maybe we should just remove the entry from the set
lists and add a note to UPDATING about deleting it manually from the
destdir in incremental builds.
PR misc/57877
thorpej