files. This is a follow up commit to r324721, which added sysrc(8) to
the SEE ALSO list.
Submitted by: Kurt Jaeger (lists at opsec.eu)
MFC after: 1 week
Now that OBJS has grown an OBJS_SRCS_FILTER variable, use this variable
in the computation of BCOBJS and LLOBJS too. Also move BCOBJS and LLOBJS
computation to be next to the OBJS computation: this should both make
the parallel structure clearer and serve to remind people changing OBJS
that parallel changes are required in BCOBJS and LLOBJS.
A side effect of this change is that BCOBJS and LLOBJS will be available
even when LLVM_LINK has not been defined, but that seems like a positive
change: there's no reason we can't ask "what bitcode files would you
generate" just because we can't link those files together into a
complete bitcode representation of a binary or library.
Reviewed by: sjg
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12701
The build rule describing how to create ${PROG_FULL}.{bc,ll} is only
dependent on LLVM_LINK being defined, not on MK_DEBUG_FILES being "yes".
Move the addition of ${PROG_FULL}.{bc,ll} out of the conditional block
under `.if ${MK_DEBUG_FILES} != "no"` and up next to where the build
rules for ${PROG_FULL}.{bc,ll} are defined.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12703
mbpool existed to support NICs with memory interfaces and all remaining
comsumers were removed earlier this year with NATM.
Reviewed by: jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10513
We previously taught the build system how to create files like libfoo.bc,
but neglected to teach it about cleaning such files up. Rectify this now.
MFC after: 1 week
Sponsored by: DARPA, AFRL
Previously before you could call unrhdr_delete you needed to
individually free every allocated unit. It is useful to be able to tear
down the unr without having to go through this process, as it is
significantly faster than freeing the individual units.
Reviewed by: cem, lidl
Approved by: rstone (mentor)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12591
All of these arguments are stored in m_ext, so there is no reason
to pass them in the argument list. Not all functions need the second
argument, some don't even need the first one. The second argument
lives in next cache line, so not dereferencing it is a performance
gain. This was discovered in sendfile(2), which will be covered by
next commits.
The second goal of this commit is to bring even more flexibility
to m_ext mbufs, allowing to create more fields in m_ext, opaque to
the generic mbuf code, and potentially set and dereferenced by
subsystems.
Reviewed by: gallatin, kbowling
Differential Revision: https://reviews.freebsd.org/D12615
When the EVENTHANDLER(9) subsystem was created, it was a documented feature
that an eventhandler callback function could safely deregister itself. In
r200652 that feature was inadvertantly broken by adding drain-wait logic to
eventhandler_deregister(), so that it would be safe to unload a module upon
return from deregistering its event handlers.
There are now 145 callers of EVENTHANDLER_DEREGISTER(), and it's likely many
of them are depending on the drain-wait logic that has been in place for 8
years. So instead of creating a separate eventhandler_drain() and adding it
to some or all of those 145 call sites, this creates a separate
eventhandler_drain_nowait() function for the specific purpose of
deregistering a callback from within the running callback.
Differential Revision: https://reviews.freebsd.org/D12561
This file shouldn't be modified manually but well, I did it in my previous
commit. So go down further the rabbit hole so as to at least keep some
consistency.
Reported by: bapt
If they are still needed, you can find them in the net/bsdrcmds port.
This was proposed June, 20th and approved by various committers [1].
They have been marked as deprecated on CURRENT in r320644 [2] on July, 4th.
Both stable/11 and release/11.1 contain the deprecation notice (thanks to
allanjude@).
Note that ruptime(1)/rwho(1)/rwhod(8) were initially thought to be part of
rcmds but this was a mistake and those are therefore NOT removed.
[1] https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html
[2] https://svnweb.freebsd.org/base?view=revision&revision=320644
Reviewed by: bapt, brooks
Differential Revision: https://reviews.freebsd.org/D12573
Make armv7 as a new MACHINE_ARCH.
Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.
Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).
Add armv7 to the universe build.
Differential Revision: https://reviews.freebsd.org/D12010
Add flag to the makefile to allow loader compilation as
Little-Endian 32-bit executable.
Usage:
make WITH_LOADER_FORCE_LE=yes -C sys/boot all
Submitted by: Wojciech Macek <wma@freebsd.org>
Reviewed by: imp, nwhitehorn
Obtained from: Semihalf
Sponsored by: QCM Technologies
Differential revision: https://reviews.freebsd.org/D12421
It was supposed to provide a recovery mechanism against bugs in procfs's
long deprecated tracing capabilities.
Remove the tool as a prerequisite to axing the kernel side.
The tracing facility to use is ptrace(2).
MFC after: 2 weeks
Some x86 class CPUs have accelerated intrinsics for SHA1 and SHA256.
Provide this functionality on CPUs that support it.
This implements CRYPTO_SHA1, CRYPTO_SHA1_HMAC, and CRYPTO_SHA2_256_HMAC.
Correctness: The cryptotest.py suite in tests/sys/opencrypto has been
enhanced to verify SHA1 and SHA256 HMAC using standard NIST test vectors.
The test passes on this driver. Additionally, jhb's cryptocheck tool has
been used to compare various random inputs against OpenSSL. This test also
passes.
Rough performance averages on AMD Ryzen 1950X (4kB buffer):
aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s
cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s
So ~4.4-4.6x speedup depending on algorithm choice. This is consistent with
the results the Linux folks saw for 4kB buffers.
The driver borrows SHA update code from sys/crypto sha1 and sha256. The
intrinsic step function comes from Intel under a 3-clause BSDL.[0] The
intel_sha_extensions_sha<foo>_intrinsic.c files were renamed and lightly
modified (added const, resolved a warning or two; included the sha_sse
header to declare the functions).
[0]: https://software.intel.com/en-us/articles/intel-sha-extensions-implementations
Reviewed by: jhb
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12452
This requests that the cipher be performed before rather than after
the HMAC when both are specified for a single operation.
Reviewed by: cem
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D11757
This was not done right when I got my ports bit, so do them both in one commit:
my ports mentors were az@ and vsevolod@ and my src mentors are avg@ and mav@
Approved by: avg (mentor)
Some makefiles do reachover builds.
In some cases it is convenient to list subdirs of the distribution
in SRCS.
It is not very convenient, or always even desirable to have corresponding
subdirs in .OBJDIR, so OBJS_SRCS_FILTER allows the makefile to choose.
The default value 'R' matches existing practice.
But a makefile can set OBJS_SRCS_FILTER= T (the R gets added by
bsd.init.mk) to avoid the need for subdirs in .OBJDIR
Differential Revision: https://reviews.freebsd.org/D12218
Reviewed by: bdrewery
Start the phasing out of TRE by disabling it by default. r317254 introduced
a BSD_GREP_FASTMATCH knob (defaulting to on) for testing of bsdgrep with and
without TRE enabled. More bugs have cropped up since then, and
WITHOUT_BSD_GREP_FASTMATCH has shown in testing to be more stable than its
counterpart.
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12381
This effectively reverts r304877, after having relegated the warning
suppression to the zic(8) makefile in r323572.
Reviewed by: emaste
Sponsored by: Dell EMC Isilon
X-Differential Revision: https://reviews.freebsd.org/D12284
in favor of just rendering the manpage instead of relying on pre-formatted
catpages. Note, this does not impede the ability to use existing catpages,
it just removes the utility to generate them.
Reviewed by: imp, allanjude
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12317
