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.
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@.
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.
that "continue" is a command as intended, and not an invalid last arg to
the '[' command (the last arg is required to be ']').
Sometime the proverbial someone should go through this and remove all the
obsolete test -o and -a operators, and probably do something with test's
usage of ! as well. Not today, or not by me anyway.
in the kernel sets. Having the .gdb kernels in the EXTRA_KERNELS does not
work, since we only walk through the standard kernels in the Makefile. Also
doing DEBUG=-g in config twice does not hurt.
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
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.
builds on modern systems and seems to have been added as a workaround for
some 2004-era Linux NFS bug. Guessing that the issue has been sorted out
in the meantime.
/netbsd/modules respectively instead of /netbsd and
/stand/<arch>/<version>/modules. This is only supported for x86,
and is turned off by default. To try it, add KERNEL_DIR=yes in your
/mk.conf and install a system from that build.
- sys/arch/evbarm64 is gone and integrated into sys/arch/evbarm. (by skrll@)
- add support fdt. evbarm/conf/GENERIC64 fdt (bcm2837,sunxi,tegra) based generic 64bit kernel config. (by skrll@, jmcneill@)
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
the support in the rest of the source tree.
X11 sets could use some cleaning up perhaps (just deletion, as
we've never really marked the old X11R6 as obsolete for native
xorg using platforms so far either.)
tsutsui