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.
Since 2008, when make generates the body of a .for loop, it does not
copy the items as raw strings but as expressions of the form ${:U...}.
This prevents syntactical changes from code injection in the body of the
.for loop.
Since then, using .for loop variables in conditions works. Since the
same time, the variable assignment operator '+=' doesn't need to be
protected by a leading space anymore. Even if the item from the .for
loop is 'libc++', the trailing '+' is not parsed as part of the variable
assignment operator, and it never had been parsed this way. The space
probably has been cargo cult programming. The only ambiguous case had
been in a variable assignment, when the variable name ended with a
variable from the .for loop, and the assignment operator was '='. Only
in this case could the parser be tricked into parsing the variable
assignment as 'libc+ +=' instead of the intended 'libc++ ='.
The condition '${dir:H} != ""' is almost always satisfied, since 2001 at
least. The only input for the modifier ':H' that leads to an empty
string is "/". It doesn't make sense though to specify the root
directory as a subdirectory.
While here, remove quotes around the left-hand side of comparisons in
conditions. The quotes have become redundant in 2008, when the .for
loop stopped inserting raw text into the .for loop body.
If the special case for "/" had actually been intended, it should have
been written as the equivalent '.if ${dir} == "/"' instead of hiding
this feature behind an edge case behavior of the modifier ':H'.
Based on the comments, the condition should have been '${dir:M/*}', but
it hadn't been written that way.
A bug in bdfload caused numchars parameter to be one less than
reality, so the last glyph was lost. It was not immediately
noticeable b/c in IBM (cp437) encoded fonts the last glyph is a
(non-breaking) space.
While here, change the font names to have -CP437 suffix.
allow conditionally disabling the building of certain user space
programs in the 'base' set.
There is not enough consensus that this is the right way and a few
people had strong objections, see source-changes-d@.
I'm pretty sure this never worked reliably based on code inspection,
and it's unlikely to have ever been tested because it only applies
when unregistering a driver -- but we have no crypto drivers for
removable devices, so it would only apply if we went out of our way
to trigger detach with drvctl.
Instead, just make the operation fail with ENODEV, and remove all the
callback logic to resubmit the request on EAGAIN. (Maybe this should
be ENXIO, but crypto_kdispatch already does ENODEV.)
- For crypto_getreq this makes downstream reasoning easier: on
success, crp_desc is guaranteed to be nonnull.
- For crypto_kgetreq, this was already assumed, just silently
ignored and not checked by anything.
Terminus Font is a clean, fixed width bitmap font, designed for long
(8 and more hours per day) work with computers.
The font has a very good script coverage and subsets with other
encodings can be imported in the future.
This commit imports IBM437 encoded (WSDISPLAY_FONTENC_ISO) subsets
converted to WSF format. wsfont metadata are stored in the files, so
you can load them without any additional arguments to wsfontload(8).
As of 10.0, tap(4) can no longer be used as a bridge(4) endpoint, so
avoid potentially confusing the reader, who'd later encounter the
caveats section, noting use of vether(4) is required instead.
first character in /etc/gpio.conf and have the rest evaluated in a
shell. It is useful to be able to do actions after setting up gpio
pins or attaching gpioiic(4).
it was found that the datasheet does not appear to provide enough
information to make use of the alarm and interrupt function work. So
actually remove the dead code that was an attempt at making that all
work. Adjust the man page to mention that this.
The names membar_enter/exit were unclear, and the documentation of
membar_enter has disagreed with the implementations on sparc,
powerpc, and even x86(!) for the entire time it has been in NetBSD.
The terms `acquire' and `release' are ubiquitous in the literature
today, and have been adopted in the C and C++ standards to mean
load-before-load/store and load/store-before-store, respectively,
which are exactly the orderings required by acquiring and releasing a
mutex, as well as other useful applications like decrementing a
reference count and then freeing the underlying object if it went to
zero.
Originally I proposed changing one word in the documentation for
membar_enter to make it load-before-load/store instead of
store-before-load/store, i.e., to make it an acquire barrier. I
proposed this on the grounds that
(a) all implementations guarantee load-before-load/store,
(b) some implementations fail to guarantee store-before-load/store,
and
(c) all uses in-tree assume load-before-load/store.
I verified parts (a) and (b) (except, for (a), powerpc didn't even
guarantee load-before-load/store -- isync isn't necessarily enough;
need lwsync in general -- but it _almost_ did, and it certainly didn't
guarantee store-before-load/store).
Part (c) might not be correct, however: under the mistaken assumption
that atomic-r/m/w then membar-w/rw is equivalent to atomic-r/m/w then
membar-r/rw, I only audited the cases of membar_enter that _aren't_
immediately after an atomic-r/m/w. All of those cases assume
load-before-load/store. But my assumption was wrong -- there are
cases of atomic-r/m/w then membar-w/rw that would be broken by
changing to atomic-r/m/w then membar-r/rw:
https://mail-index.netbsd.org/tech-kern/2022/03/29/msg028044.html
Furthermore, the name membar_enter has been adopted in other places
like OpenBSD where it actually does follow the documentation and
guarantee store-before-load/store, even if that order is not useful.
So the name membar_enter currently lives in a bad place where it
means either of two things -- r/rw or w/rw.
With this change, we deprecate membar_enter/exit, introduce
membar_acquire/release as better names for the useful pair (r/rw and
rw/w), and make sure the implementation of membar_enter guarantees
both what was documented _and_ what was implemented, making it an
alias for membar_sync.
While here, rework all of the membar_* definitions and aliases. The
new logic follows a rule to make it easier to audit:
membar_X is defined as an alias for membar_Y iff membar_X is
guaranteed by membar_Y.
The `no stronger than' relation is (the transitive closure of):
- membar_consumer (r/r) is guaranteed by membar_acquire (r/rw)
- membar_producer (w/w) is guaranteed by membar_release (rw/w)
- membar_acquire (r/rw) is guaranteed by membar_sync (rw/rw)
- membar_release (rw/w) is guaranteed by membar_sync (rw/rw)
And, for the deprecated membars:
- membar_enter (whether r/rw, w/rw, or rw/rw) is guaranteed by
membar_sync (rw/rw)
- membar_exit (rw/w) is guaranteed by membar_release (rw/w)
(membar_exit is identical to membar_release, but the name is
deprecated.)
Finally, while here, annotate some of the instructions with their
semantics. For powerpc, leave an essay with citations on the
unfortunate but -- as far as I can tell -- necessary decision to use
lwsync, not isync, for membar_acquire and membar_consumer.
Also add membar(3) and atomic(3) man page links.
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
- For the main warning message, use less jargon, say `security', and
cite the entropy(7) man page for further reading. Document this in
rnd(4) and entropy(7).
- For the debug-only warning message, say `entropy' only once and omit
it from the rnd(4) man page -- it's not very important unless you're
debugging the kernel in which case you probably know what you're
doing enough to not need the text explained in the man page.
This simplifies the rndsource API -- no need to lock, unless you're
also coordinating with other driver logic like concurrent
opencrypto(4) requests that share device requests.
May need access to the global entropy pool (infrequently). This way
the global entropy pool lock can be lowered to IPL_SOFTSERIAL too,
with a little additional work.
Since usr.bin/xlint/lint1/tree.c 1.202 from 2021-01-31, lint recognizes
the common idiom 'do { ... } while (0)' and no longer complains about
its constant condition; see tests/usr.bin/xlint/lint1/msg_161.c.
The only purpose of the enum example is to show that enum constants are
written in uppercase.
The previous code could be mistakenly interpreted as requiring each
definition of an enum type to also define a global variable of that
type, and to make the variable name the abbreviated type name. Even if
the enum type were prefixed with 'typedef', choosing different names for
the tag and the typedef would not be necessary.
To avoid these possible misinterpretations above, remove the variable
name from the declaration.
I'm not documenting this to encourage anyone to use it. I'm only
documenting this to remind myself what the semantics is, because it's
kind of confusing and not at all like mutex(9).
This doesn't mean you should use it! Mostly it's to document the
semantics to help understand existing uses, which should not
proliferate, and audit definitions.
add support for 8-bit and I2C variants of the chip:
- MCP23008 / MCP23S08: 8-bit (I2C / SPI)
- MCP23017 / MCP23S17: 16-bit (I2C / SPI)
- MCP23018 / MCP23S18: 16-bit (I2C / SPI), open-drain outputs
The MCP23x17 and MCP23x18 are essentially identical, software-wise; we
merely report different GPIO pin capabilities (no push-pull output for
MCP23x18). Also, remove the tri-state capability that was previously
advertised by the old version of this driver; these chips have no way
to put the pin into a HI-Z mode.
All 3 I2C versions are supported, but the SPI front-end still only
supports the MCP23S17 for now (SPI autoconfiguration needs an overhaul).
mcp23s17gpio(4) remains present as a link to the new mcpgpio(4) man page.
XXX Still to-do: FDT integration, interrupt suppoort.
a function to be called before the destructor for a batch of one or more
objects is called. This can be used as a synchronization point by
subsystems that rely on the type-stable nature of pool cache objects or
subsystems that use other forms of passive serialization.
MKKDEBUG -> MKDEBUGKERNEL
MKTOOLSDEBUG -> MKDEBUGTOOLS
while keeping compatibility with the old names. Add missing documentation.
Now all debugging tunables are prefixed with MKDEBUG.
as the name implies, includes a netbsd.gdb inside each kernel set:
$ tar -tzvf kern-GENERIC.tgz
-rwxr-xr-x 0 root wheel 29398264 Dec 19 12:50 ./netbsd
-rwxr-xr-x 0 root wheel 208125880 Dec 19 12:50 ./netbsd.gdb
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.
libraries. We want to lint the private library code and we want to be able
to link against the lint libraries, for example llib-largon2 from cgdconfig
which is accessed via PROGDPLIBS.
The character class contained two times U+0020, which makes one of them
redundant, so remove the character class. PR toolchain/18248 already
contained these two spaces.
Apparently there is no need to support tabs in this place, otherwise
someone would have noticed it in the 17 years since this pattern had
been added in sys.mk 1.83 from 2004-01-27.
No functional change.
heater element. Disable the heater features in the driver when that
condition is detected and let the attachment succeed. Also mention
that the SHT21 is another clone.
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.
- Tweak title.
- Clarify semantics -- round down, not any other way.
- xref ffs(3)
- Fix return type: int.
- Fix language about input type.
. Any unsigned type is fine.
. Types smaller than uint32_t will be safely converted to uint32_t.
- Note that it is a constant expression if x is constant.
partial RELRO when MKRELRO=full is set.
Currently the X server needs to be compiled with only partial RELRO
due to the way certain (but not all - it seems wsfb works with full
RELRO) graphics driver modules are loaded.
As well as offering a dynamic amount of iterations and memory usage,
which fits well with NetBSD's goal of running on a diverse range of
hardware devices, Argon2id offers improved resistance to GPU-based
password cracking and side channel attacks.
Normally, functions called from mcount.c are expected to be expanded inline,
so _mcount() will never be called recursively. But when build with COPTS=-O0,
`static inline' functions aren't inlined, and _mcount() will be called
recursively.
Even if _mcount() has `__attribute__((__no_ instrument_function__))',
it has no effect on the calling external (no-inlined) function.
To avoid this, PROF.<fn> is added can be set the profiling flag of any file.
"PROF.mcount.c" is set to blank by default, mcount.c itself is compiled
without -pg.
chip from Adafruit is:
https://www.adafruit.com/product/4829
This is a moderately priced gas sensor that can detect volatile
organic compounds in the air. The driver uses the 3-clause BSD
licensed VOC algorithm provided by Sensirion to turn the raw sensor
metric into a VOC index which can indicate the quality of the air in a
particular indoor environment. All published functions of the chip
are supported and one unpublished feature.
There may have been a technical reason for this back when we were
following the expired passive serialization patent to the letter, but
no more -- and this is a real burden for some applications.
sensor. An example of this chip is:
https://www.adafruit.com/product/4885
This is a lower cost chip that provides higher then usual precision
according to the data sheet. This driver supports all of the published
functions that the chip has.
This set is only installed on amd64,i386,evbarm.
This set is installed on minimal installs and on install media, in
case someone needs it for basic driver functionality.
Comments:
Switched to a single MK tunable for it - that is probably unneeded.
An upcoming DRM update will include even fatter firmware, and we'd
like to minimize the impact of it.
Bump date.
XXX1: the wskbd(4) (and all otther wscons(4) related) man page should
describe more details of all ioctls.
(usage, args and return values including structures).
XXX2: the wsbell(4) man page has description about all WSKBDIO_*BELL ioctls
and struct wskbd_bell_data, but maybe they should be moved into this
wskbd(4) man page and wsbell(4) should be changed to xref wskbd(4).
no idea why it was enabled as we can't easily target 32 bit.
if we figure this out for aarch32, the subdir names etc will
probably be different, or we can just revive the deleted
files no longer referenced with this commit.
pgoyette