enabled and don't warn our users that it might not and already suggest
workarounds.
The ability to disable ACPI and SMP is still there, by dropping to
the boot prompt.
images, but also on the bootable disk images of other ports, so that
they can be booted from differently named devices. Merge the i386 and
amd64 -live-sd0root and -live-wd0root images into a single live image
per port, bootable both from usb media and in qemu. Drop the -xx0root
suffixes from image names as they are no longer meaningful.
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.
While there fix an old bug that makefs used the build hosts /etc/group
and passwd information when creating the image.
Thanks to Andreas Gustafsson for extensive testing.
amd64/ramdisks/common/list.ramdisk.
Previously, the amd64 list.ramdisk used the small version of gzip from
distrib/utils/x_gzip, while the i386 list.ramdisk used the full version
of gzip built from usr.bin/gzip, and also used extra libraries needed to
make that work. Now, they both use the small version.
The only other difference was in the order of some PROG lines.
pre-define the LISTS variable if they do not want it to include
${.CURDIR}/lists. This opens the possibility of making some of the
many distrib/*/ramdisks/*/lists files shared in the future.
XXX: Some of the differences between these files seem to be unnecessary.
conversion of some constants to variables, this is identical to the code
that was previously present in both distrib/amd64/kmod/Makefile and
distrib/i386/kmod/Makefile.
Change distrib/amd64/kmod/Makefile and distrib/i386/kmod/Makefile to just
set some variables and .include "../../common/Makefile.minirootkmod".
to incorporate the OS name and version.
XXX should also not hardcode ${BOOTDISK} in the name, but that would
require reordering stuff and more testing than I have time for right now.
Another day.
As discussed on current-users@ back in March, with some adjustments.
depend on new devname_r(3) as heart. Add /dev/pts magic directly to
devname(3). While it can lead to returning non-existing paths, the
behavior is more consistent that way. Drop caching layer in devname(3),
it doesn't buy anything for the common case of having access to the
database. Teach devname(3) proper fallback behavior of scanning /dev.
Create both old-style and new-style database for now in /etc/rc.d/sysdb.
