attach message.
For depth == 32, fix ``0 color'', and prevent ambiguous ``16Mi color''.
I don't know whether there is 24-bpp graphic card for mac68k or not,
although.
The bug was introduced in var.c 1.323, which merged two flags that
sounded as if they had been exact opposites: VAR_NOSUBST (later named
VARE_NOSUBST) and VARE_WANTRES.
Before that commit, the branch where make only counted braces instead of
properly parsing the nested expression was only taken in the modifiers
':@var@body@' and '::=', but not in ':S' and ':C'.
After merging the two flags, the modifier parts of ':S' and ':C' had to
be balanced as well, otherwise parsing would fail in cases where the
expression was only parsed, not evaluated.
Came here because lint complained about non-constant case expressions in
sys/arch/xen/xen/xennet_checksum.c, line 111 and 122, which read:
case htons(ETHERTYPE_IP):
case htons(ETHERTYPE_IPV6):
POSIX says:
On some implementations, these functions are defined as macros.
NetBSD implements these functions as macros, and on little-endian platforms,
as well as in lint mode, the macros expand to function calls.
-b (from FreeBSD) - set blocksize to blocks (512 bytes)
(overrides a contrary setting in BLOCKSIZE)
-H (from FreeBSD and Linux): -h using SI units (powers of 10). Ugh.
-N suppress the header line (except with -P which requires it).
-f show only free space (or inodes) in a minimal format (implies -N)
(that is, with one file[system] specified, print 1 number only)
With -c, show only the total.
Intended to be useful for scripting (aka, I needed it.)
While here, improve the usage message (group options where they apply,
there is no reason, for example, that -g should be shown differently
to -k -m ..., and those options aren't at all useful with -G)
Update the man page to match.
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>
I don't know why this was ever enabled by default; many modules are
still not safe to unload, let alone autounload. If any autounload is
to happen by default, it should only be for modules that have opted
into it in some way after audit.
They are called in reverse topological order on unload.
dtrace_sdt will rely on this soon to ensure provider definitions are
processed before their uses.
ok chs@
- Enable UFS_DIRHASH if the architecture or kernel model specific config
file can use 128MB of RAM or more.
- Remove experimental tag from UFS_DIRHASH; it's been with RUMP kernel
and by a number of NetBSD developers for years.
- Add LFS_DIRHASH if LFS was enabled.
- Be somewhat consistent with FS options order.
size dependant on memory size. If less than 128MB of memory, default
to no cache. With 128MB of memory or more, use a maximum cache size of
1/64th of memory; cap maximum default cache size to 32MB (for systems
with 2GB of memory or more).
The dirhash cache sizes are still explicityly setable by sysctl(8) or
by adding relevant entry(s) to sysctl.conf(5).
gcc generates calls to this symbol in programs that use
__sync_*_compare_and_swap, which require full sequential consistency
barriers, including store-before-load ordering on both sides of the
atomic; none of the release/acquire operations guarantee that, so we
have to insert explicit DMB instructions.
Note: gcc's own definition omits some of the DMB instructions, but I
can't prove that it's correct that way -- stores preceding the CAS
must complete before the load part of the CAS, and the store part of
the CAS must complete before loads following the CAS. Maybe there's
some way to prove that one of these orderings is guaranteed some
other way than a DMB but I'm not seeing it, and store-before-load
ordering is hard to understand.
Patch by skrll@ based on a patch by mrg@, soliloquy in commit message
by me.
In the modifier ':S,from,to,', parsing the two parts 'from' and 'to' of
the modifier differs depending on whether the expression is actually
evaluated or merely parsed. This not only applies to the ':S' modifier,
but also to ':C', ':@var@body@', ':!cmd!', ':[...]', ':?:', '::=' and
':from=to'.
riastradh