This is intended to be a tree-wide revision identifier, like a commit
hash or similar. This way, in builds from non-CVS trees where
per-file $NetBSD$ revision ids aren't incremented, we can still track
some version provenance of files with ident(1).
If defined, bsd.own.mk adds a macro _NETBSD_REVISIONID to CPPFLAGS
with the stringified text of NETBSD_REVISIONID.
In turn, if _NETBSD_REVISIONID is defined in sys/cdefs.h, then
__RCSID will put the concatenation of:
- `$NetBSD: '
- the file name
- ` '
- _NETBSD_REVISIONID
- ` $'
alongside the per-file revision id passed as an argument to __RCSID.
Since this is passed through command-line arguments, it doesn't cause
make to consider any dependencies to change when the revision id
changes -- so incremental builds remain incremental. And if you
don't set it, nothing changes from the __RCSID we had before.
Currently nothing sets NETBSD_REVISIONID automatically yet -- subject
to experimentation. Could just be verbatim commit hash, or could be
longer `hg identify' output -- or, in git, with the help of tags,
could be `git describe --dirty' output like
10.99.10-2924-gd01834fb75de
(or `10.99.10-2924-gd01834fb75de-dirty' if the working tree is dirty)
for the commit at
https://mail-index.netbsd.org/source-changes/2024/05/24/msg151526.html
which is 2924 linear commits after the commit bumping sys/param.h to
10.99.10 and (in the current git conversion) had commit hash starting
with d01834fb75. This may require some discipline around branching
and tagging but it's worth a shot -- we'll see.
Based on a patch from joerg@ a while ago.
Explicitly say that "delta" is optional and may be zero. While this
hasn't previously been specified anywhere (to my knowledge), the best
de-facto specification we have (sb and mixerctl source code) points
towards the historical practice being there.
. In particular, add NetBSD 8.3 to timeline
. Add respective "publication dates" of those points in time
While here, also:
. Fix white space idiosyncracies and opt for https instead of http
. Track some changes made to the FreeBSD version of this file
On this architecture vmt(4) used to search for a node "/hypervisor" in the
FDT and probed the VMware hypervisor call only when the node was
found. However, things appear to have changed and VMware no longer provides
the FDT node.
Since vmt(4) doesn't actually need to read anything from FDT, and the
hypervisor call logically resides in virtual CPUs themselves, it would be
better to attach it directly to cpu, just like how it's probed on x86.
Otherwise, we get the wrong list of symbols for compat library
builds, where MACHINE_ARCH/CPU is different from
LIBC_MACHINE_ARCH/CPU, e.g. building compat 32-bit sparc libm on
sparc64.
XXX This is kinda kludgey -- `libc' seems wrong here.
this reduces the size of the installed files by over half in most cases,
though the debug set size doesn't really change much (which looks like
close to 1GB of space on amd64 with xdebug installed, similar on arm64,
and about 600MB without xdebug.)
tested by running GDB on a few things, seems just as functional, on amd64,
arm64, and slightly on riscv64.
(first attempt for this feature used "gcc -gz=zlib", but that ends up
making CTF unhappy, but fortunately this works in binutils to create
the .debug files separate to any ctf usage of the main file.)
documented cpuid instruction and eax register.
This approach is adapted from linux via-cputemp.c, no official documentation is
currently available. However, msr value seems to work on all tested CPUs while
documented cpuid instruction typically reports 0, even for my C7-D CPU.
msr value seems to have temperature in Celsius in lower 24-bits without fraction
(thus "msr & 0xffffff;" is used).
Tested on my personal systems based on CPUs below (i386 and amd64):
C7-D 1.6GHz (i386 only), Nano X2 L4350E, Nano X2 U4300, U2300 Nano, KX-U6580.
Also got one response via email which was based on Nano X2 L4050 (VE-900).
Nano reports independent values for each core.
KX-U6580 seems to show the same value for all cores but more testing is needed.
Since it works on amd64 capable CPUs, adding driver to GENERIC kernel config.
Also moving viac7temp man page to x86 instead of i386 (with updates).
In theory the change should add support for all VIA Nano CPUs and Zhaoxin CPUs
at least up to KX-6000(G) series.
In the future I may need to introduce amd64 kernel module as well.
Plan to pullup to at least netbsd-10.
Patch mainly reviewed by riastradh.
It's too big for the i386 install media and not useful on either
pre-2012 hardware or the kinds of embedded systems where i386 still
thrived after 2012.
(The build of the kernel parts of amdgpu on i386 is nevertheless useful
for finding obscure bugs.)
"go for it" riastradh
MAKELINKLIB that follows MKLINKLIB but can be overwritten by Makefiles
MAKESTATICLIB that follows MKSTATICLIB but can be overwritten by Makefiles
LINKINSTALL that follows MAKELINKLIB but can be overwritten by Makefiles
These give enough control to the module Makefiles so that they don't need
to override the default library install rules which break the debug sets.
- Remove /usr/libexec/named which duplicated /usr/lib/named
- Use ?=, not =, so mk.conf setting wins.
- Write out per-architecture tabular settings, not a conditional.
- Add comments for the architectures that look like they should have
sljit but don't. (XXX Missing comments about powerpc and mips --
not sure why, is this because modules don't yet work on those
architectures, or what?)
Tidying for PR 58103: bpfjit.kmod is not built on aarch64.
tsutsui