These changes are to prepare for the removal of arch/arm/omap. Support
for Xscale based Gumstix platforms remains.
(If someone wants to resurrect DuoVero and Pepper platforms, it's best
to do that in the GENERIC kernel using FDT.)
Be able to change the behavior sending parameter changing routing messages.
When set net.inet6.ip6.param_rt_msg=0, don't send parameter changing
routing messages.
When set net.inet6.ip6.param_rt_msg=1(default), send parameter changing
routing messages by RTM_NEWADDR.
The previous range introduced in time.h rev1.14 was supposed to account
for a mystical "double leap second", which ultimately never could exist
and was a mistaken interpretation from an early ISO C standard whereby
the possibility of two leap seconds within a year was erroneously
interpreted to mean that two leap seconds could occur at once.
(previously 10.0.0):
http://www.unicode.org/charts/
They are classified as PUNCT, which has been used for characters other
than blank, alphabetic, or digit ones.
Glyph widths are taken from "East Asian Width":
https://www.unicode.org/Public/15.0.0/ucd/EastAsianWidth.txt
Characters of "F" or "W" are classified to SWIDTH2, and others are to
SWIDTH1, as usual. See also:
https://www.unicode.org/reports/tr11/
XXX
It would be really nice if someone could check and update characters in
categories other than Emoji...
Note that vmem_alloc and vmem_xalloc have failure modes -- failing
with ENOMEM despite VM_SLEEP, or importing or sleeping forever --
that appear to be bugs when align/phase/nocross/minaddr/maxaddr are
specified.
Some routing daemons require such routing message to keep coherency.
If we want to let kernel send such message, set net.inet.icmp.dynamic_rt_msg=1
for IPv4, net.inet6.icmp6.dynamic_rt_msg=1 for IPv6.
Default(=0) is the same as before, that is, not send such routing message.
If we want to use path MTU discovery for icmp reflecting set
net.inet6.icmp6.reflect_pmtu=1. Default(=0) is the same as before, that is,
use IPV6_MINMTU.
Release builds for arm platforms create compressed images in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. However, in some
cases, e.g., armv7.img.gz, they are not bootable. Consequently, boot
blocks must be manually installed in the images, which is an extra
barrier for testing systems or adopting NetBSD. This has prompted
creation of external repositories, e.g., armbsd.org, to host a
collection of bootable images. However, this does not ease the burden
on developers compiling their own systems; for them, manual
installation of boot blocks is still required.
For arm platforms, etc/etc.evbarm/Makefile.inc contains the commands
used to create system images. Because installboot(8) can write boot
blocks directly to system images, a loop through possible boards can
create a series of bootable images during the normal build process.
In the case of many arm platforms, installboot(8) uses U-Boot boot
blocks, which are not part of the NetBSD source code. Developers can,
however, install as many U-Boot boot blocks as desired, either in the
default location of /usr/pkg/share/u-boot or in a set of directories
pointed to by the U-Boot search path, the INSTALLBOOT_UBOOT_PATHS
environment variable. For each board with an available boot block, a
board-specific bootable image will be created in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. If a boot block is
not available, which is the typical situation currently, no additional
image will be created.
This facility creates opportunities to build bootable images for any
number of boards within the scope of a standard release build.
However, that is not required and will not occur without the
intervention of installing U-Boot boot blocks prior to the build.
Remove support for building extsrc/:
1. Makefile: remove do-extsrc target.
2. build.sh: remove options -y and -Y extsrcdir.
3. distrib/sets: remove support for extsrc in various tools
including the options -L ext and -y, and the extsrc sets.
4. doc/BUILDING.mdoc: remove docs for extsrc/, EXTSRCSRCDIR, MKEXTSRC (etc)
5. bsd.own.mk and various Makefiles: remove support for extsrc/,
EXTSRCSRCDIR, MKEXTSRC.
As proposed on tech-kern and tech-userlevel on 2022-01-07
and followed up on 2022-08-21.
As proposed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2022/07/16/msg028249.html
tl;dr:
- bus_space_barrier is needed only with prefetchable/cacheable.
- BUS_SPACE_BARRIER_READ is like membar_acquire.
- BUS_SPACE_BARRIER_WRITE is like membar_release.
- READ|WRITE is like membar_sync.
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.)
two years; that is, since May 2020 after NetBSD 8.2 was registered
in this file.
Merge some additional information from the FreeBSD and DragonFly
versions that had several updates during this time. Added OpenBSD
and macos release dates for the same interval.
Where some release dates don't match exactly (release vs. announce
date) in the various bsd-family-tree files, assume the respective
flavor to be authoritive for its dates in this file.
Reviewed by: Sergey A. Osokin <osa@NetBSD.org>
The type-limits warning is actively harmful because it discourages
writing safe portable overflow detection logic which happens, on some
architectures, to be dead code.
Make it easier to test this one out, add `load amdgpu` before boot netbsd.
XXX there should probably be a drm block in sys/modules/Makefile which
includes aarch64.
jmcneill