- 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.)
The BUILDINFO string will appear nearthe top of /etc/release,
indented by 8 spaces and with a blank line above and below it,
but without a heading. The BUILDINFO string is expected to
be self-explanatory.
Also change some other headings near the top of /etc/release.
This prevents it from embedding a timestamp in the output. We pass
"-n" unconditionally, not conditional on MKREPRO, because many other
invocations of gzip already passed the -n flag unconditionally.
RELEASEVARS variable, and commands related to printing the values of
the variables whose names are in RELEASEVARS.
Add an awk script to remove noise printed by "make -j" or high levels
of MAKEVERBOSE, so we get only the variables names and values. The
values are escaped so that variables containing embedded newlines,
quotation marks, and backslashes, are passed through safely.
Adapt src/etc/Makefile and src/Makefile to use the new ${PRINT_PARAMS}
command defined in src/etc/Makefile.params.
Now ${DESTDIR}/etc/release and the params file in the top-level
.OBJDIR should never contain unwanted noise, even after a build with
MAKEVERBOSE=4.
Makefile to use the new ${_NETBSD_VERSION_DEPENDS} mechanism defined in
bsd.own.mk.
Rename the default motd file in the source tree from "motd" to
"motd.default", because otherwise it would conflict with the motd file
that is now created in the .OBJDIR.
rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
get automatically appended to etc/defaults/rc.conf at build time if present.
This is used by i386 and amd64 to append a small MD rc.conf(5) configuration
at the end of the defaults/rc.conf file, so that powerd(8) can be started
by default when we are running in a Xen environment. This is needed to support
save/restore functions for domains.
From all the alternatives proposed to fix that issue (from /etc/rc.conf
parsing in postinstall to etc/defaults/rc.conf arch-hooks) I believe
this one will appease everyone because it:
- does not touch etc/defaults/rc.conf template file,
- patches it at build time for MD hooks only when required,
- does not need to parse/modify a user-specified file like /etc/rc.conf (which
is a complex, error-prone operation),
- only enables powerd(8) by default when conditions are met (Xen environment)
while still allowing root to shoot himself in the foot if he wants to
override this manually in /etc/rc.conf.
See also http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html
ryo