In the last 18 months, several lint warnings have been made adjusted to
allow common usage patterns. For example, lint no longer warns about a
constant condition in the statement 'do { ... } while (false)' (message
161), as this pattern is well-known in statement-like macros, making it
unlikely that the 'false' is a mistake. Another example is casts
between unequal pointer types (message 247) for a few well-known
patterns that are unlikely to be bugs.
Occasionally, it is useful to query the code for patterns or events that
would not justify a warning. These patterns are modeled as predefined
queries that can be selected individually, in addition to and
independently of the existing warnings and errors.
New queries can be added as needed, in the same way as new warnings.
Queries that are deemed no longer used can be deactivated in the same
way as warnings that are no longer used.
As long as none of the queries is enabled, they produce a minimal
overhead of querying a single global variable. Computations that are
more expensive than a few machine instructions should be guarded by
any_query_enabled.
https://mail-index.netbsd.org/source-changes-d/2022/06/28/msg013716.html
ok christos@
Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.
The test had been wrong since msg_132.c 1.14 from 2022-05-30.
Using 'unsigned long' in a test that was intended to behave the same on
ILP32 and LP64 was an accident. Use 'unsigned long long' instead, which
is 64-bits wide on all platforms supported by lint.
Move the test about conversion from 'long' to 'int' to the
platform-specific test files.
Noticed by martin@ on powerpc.
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@.
This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):
SYNOPSIS
#include <unistd.h>
int getentropy(void *buffer, size_t length);
DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.
RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.
ERRORS
The getentropy() function shall fail if:
[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.
The getentropy() function may fail if:
[ENOSYS] The system does not provide the necessary
source of entropy.
RATIONALE
The getentropy() function is not a cancellation point.
Minor changes from the previous introduction of getentropy into libc:
- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.
The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.
strictly-aligned versions of memcmp(3), bcopy(3), memcpy(3), and
memmove(3).
This is used for 403 by ld.so.conf with machdep.no_unaligned variable.
With this library, unaligned memory accesses are significantly reduced
for 403 (from several hundreds to few tens per sec under heavy load);
only ld.elf_so (typically few times per fork) and statically-linked
binaries do such access.
PR bin/43821 describes the inconsistency that in a '.for i' loop, the
condition '.if ${i:M*.c}' works since 2009 while the seemingly
equivalent condition '.if !empty(i:M*.c)' does not access the variable
'i' from the .for loop but instead the global 'i'.
Resolving this situation in a backwards-compatible and non-surprising
way is hard, as make has grown several features during the last 20 years
that interact in various edge cases. For now, document the most obvious
pitfalls.
radeon has different case but same name firmware files. the lower case
ones are already installed into /libdata/firmware, and to avoid having
to provide some special method to build on systems with case-preserving
file systems (such as macOS), we install the lower case ones in /usr.
this means that anyone that requires the lower case files must either
have /usr as part of the / file system, or manually keep them updated.
last part of PR#54976, though i doubt we'll try to pull up these.
this is enabled on i386, amd64 and arm64.
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).
The change in lex.c 1.129 attempted to add support for __alignof, in
addition to the existing support for __alignof__. It failed by removing
support for __alignof__, while allowing the plain 'alignof' instead.
- Drop FD support from installboot(8). Reduce ~0.5KB.
- Drop primary boot loaders for FD (2 files, 0.5KB each).
Note that we continue to support these features in base.
OK tsutsui@
bump the size of images if USE_XZ_SETS != no. consolidate a lot of
the code between installimage/Makefile and installimage-bios/Makefile
into installimage/installimage.mk.
The tests in cond1 were a mixture of "everything related to conditions",
and the test cases were heavily dependent on each other, which made them
hard to understand. Move each test case to its corresponding
special-purpose test.
Restore the grammar rule for labeled_statement as it was before cgram.y
1.400 from 2022-04-24. This allows labels with attributes again. Fix
the wrong interpretation in the tests; the attributes belong to the
label, not to the statement.
Today in the morning, when I thought that the change in cgram.y 1.400
were innocent, I accidentally ran lint only with the options '-Sw' but
forgot the option '-g' for GNU mode. Without that option, the token
'__attribute__' is unknown, which unsurprisingly leads to lots of syntax
errors, and these didn't change with that commit. The actual change was
only visible in GNU mode.
Use the final version of firmware provided for these cards. This has
been tested with both variants of impacted iwn(4) cards (6005_2X2_1 and
6005_2X2_2, as found in a Dell E6230 and a Lenovo T420), improvements
noted.
In indent.h 1.49 from 2021-10-25, the enumeration token_type was split
into lexer_symbol and parser_symbol to more clearly express that these
tokens fall into completely different classes of usage patterns.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
says that in order to make a makefile POSIX-conforming, its first
non-comment line must be the special dependency line '.POSIX:' without
any source dependencies.
Previously, make switched to POSIX mode even if such a line occurred
anywhere else, which was allowed by POSIX but was deep in the
"unspecified behavior" area. For NetBSD make, there is no big
difference since it doesn't ship any <posix.mk> file, this change mainly
affects the bmake distribution.
Previously, makefiles that contain '.POSIX:' somewhere in the middle
could fail due to <posix.mk> resetting .SUFFIXES, among other things.
Suggested by Simon J. Gerraty, who also reviewed an earlier version of
this change.
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.
These tests run two threads for five seconds each to try to trigger
races in the event of broken memory barriers. They run only on
machines with at least two CPUs; on uniprocessor systems there's no
point -- the membars can correctly just be (instruction barrier)
no-ops.
Floppy generation was disabled before NetBSD 6.0 release due to size
constraints and unlikely to be restored soon or at all. PR port-sparc/56776.
ok martin.
the iic module. There are valid configurations where i2c_subr code
can be both built-in and part of a loaded module (eg, piixpm is in
the kernel, but the iic module is loaded later). This causes the
in-kernel linker to detect a duplicate symbol.
XShapeQueryExtension.3 and XShapeQueryVersion.3 are not conjoined twins.
While here split XShape.3 links into separate MLINKS += src dst assignments
and sort them.
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.
mrg