Proposed on the the tech-userlevel mailing list without strong objections.
This file no longer serves any purpose in any supported release branch.
There will be fallout in pkgsrc, please restrict inclusion <sys/user.h> to
FreeBSD and DragonflyBSD.
I tried to iterate over packages in pkgsrc and there was little fallout,
however I don't have the full sources to scan every source code. I already
upstreamed to several projects removal of inclusion on NetBSD of
<sys/user.h> (like Qt5).
We used -DSMALL to exclude code from libc in order to build
libhack. Introduce -DLIBHACK to do this without so that
-DSMALL does not remove code necessary for building a shared libc
digittoint(3).
The digittoint(3) test is skipped since we don't provide that function yet.
One of the test cases for btowc(3) is also skipped, since it tests conversion
to Unicode---whereas our wchar_t representation is locale-dependent.
CAN stands for Controller Area Network, a broadcast network used
in automation and automotive fields. For example, the NMEA2000 standard
developped for marine devices uses a CAN network as the link layer.
This is an implementation of the linux socketcan API:
https://www.kernel.org/doc/Documentation/networking/can.txt
you can also see can(4).
This adds a new socket family (AF_CAN) and protocol (PF_CAN),
as well as the canconfig(8) utility, used to set timing parameter of
CAN hardware. Also inclued is a driver for the CAN controller
found in the allwinner A20 SoC (I tested it with an Olimex lime2 board,
connected with PIC18-based CAN devices).
There is also the canloop(4) pseudo-device, which allows to use
the socketcan API without CAN hardware.
At this time the CANFD part of the linux socketcan API is not implemented.
Error frames are not implemented either. But I could get the cansend and
canreceive utilities from the canutils package to build and run with minimal
changes. tcpudmp(8) can also be used to record frames, which can be
decoded with etherreal.
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.
These tests are cloned from t_cxxruntime and check proper order of destructor
calls. They must be reported in reverse order of constructor completion.
Added tests:
- static_destructor
- static_destructor_pic
- static_destructor_pie
- static_destructor32
This test file replaces src/regress/usr.bin/c++/static_destructor.
This is a copy of t_hello from usr.bin/cc.
Added tests:
- hello
- hello_pic
- hello_pie
- hello32
These tests do not use c++ runtime library functions.
Protect these tests with MKCXX.
This as discussed on current-users in the thread
entitled:
Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
that can be found (starting at):
http://mail-index.netbsd.org/current-users/2017/04/28/msg031600.html
These functions provide the mechanism to enable applications
to divorce themselves from internal details of the signal
implementation.
Libc minor bumped, prototypes in <signal.h>, sets lists updated (and sorted).
One and all: feel free to improve the sources & man page (etc), but
please do not change the function signatures without discussion.
