Previously, passing '-nostdinc -isystem $dir' only searched the given
directory but not any compiler-specific directories.
Discovered by fontconfig, which includes <stdatomic.h> from C11, which
lives in /usr/include/gcc-10 instead of /usr/include.
Change the preprocessor options to '--sysroot' instead, to align them
with how the compiler is invoked using build.sh.
The variables MACHINE and MACHINE_ARCH are guaranteed to be defined,
therefore they don't need to be wrapped in '!empty(...)'.
This is simpler to read and, in case of typos, is more likely to lead to
an error message from make, as a line starting with '!' is interpreted
as a dependency line, while a line using only '==' but not '!=' leads to
a syntax error of the form 'Invalid line type'.
issue with +2M size in every binary by setting max-page-size. This
is the simplest fix; fixing this properly requires a lot more
surgery, and upstream seems uncertain how to fix it properly.
Written by Hiroshi Noguchi, of which an updated version was posted to
port-mac68k in 2001.
Attachments were added to kernel configs for platforms that already had
the Cabletron (se.4) driver added, although other platorms may benefit.
Reviewed on tech-net by Izumi Tsutsui.
this fixes a build issue seen where the host pixman.h was included,
and has been problem ever since tsutsui fixed my original code (from
2008) about 29 months ago. i'm surprised this has not been seen
anywhere else in that time.
XXX: pullup-10
This version of the file, and the generator script, come from
OpenBSD. The script was written by Andrew Fresh.
The file covers the encodings from Unicode 13.0.0, based on the files
distributed with perl 5.32.1.
Untabify examples, .Bd -literal -offset indent doesn't seem to mesh
with tabs nicely in the PostScript output. The indent is probably not
a multiple a of literal tab width. This causes a small vertical
misalignment for tab-indented lines, but what's worse - it can cause
an extra tab in some cases (and did here for the unpcbid definition).
atmospheric pressure sensor. This is an inexpensive to moderately
expensive chip available from a large number of places. The driver
supports all aspects of the two chips, except for the repeating read
mode which would allow for sub-second queries, such as fall detection
or perhaps even as an altimeter. This driver also only supports the
I2C interface and not the SPI interface.
The BME280, the one with humidity, is not fully tested at this point,
awaiting upon a breakout board and may not show proper humidity.
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.
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.
christos