This is purely to make it easier to tweak them locally; the machine I have
for testing takes forever to do 50,000 pw strengthening iterations, and
we're not testing the strength of geli's anti-pw-guessing logic here
(especially given that our test passphrase is "passphrase", except that
I tend to tweak that also, to 'x', because typing is hard).
Some day these should be settable as cmdline args. But then, some day this
whole script should probably get a rewrite. :)
This will disable the new LLVM_TARGET_ALL option which will only
enable the required target.
This only impacts the bootstrap compiler in WORLDTMP, not the target compiler
that will be installed.
MFC after: 2 weeks
Reviewed by: sbruno, dim (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D16021
LLVM_TARGET_* will auto be set based on LLVM_TARGET_ALL and MK_CLANG.
If LLVM_TARGET_ALL is disabled, during a cross-build, then SYSTEM_COMPILER
and SYSTEM_LINKER are auto disabled.
This option should be used by users rather than the per-arch LLVM_TARGET
options as it is simpler to maintain for them should the supported
target list change.
MFC after: 2 weeks
Reviewed by: sbruno, dim
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D16020
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
The new stand/ structure installs loader.conf(5) and defaults/loader.conf
regardless of interpreter. The only thing gating installation now is
MK_BOOT.
Reported by: eadler
This works similar to WITH_SYSTEM_COMPILER added in r300354. It only
supports lld via WITH_LLD_BOOTSTRAP.
When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
will not build in cross-tools. If either check fails though then
libclang is built.
The .info is reworked to notify when libclang will be built since if
either clang or lld needs to be rebuilt, but not the other, the
notification can lead to confusion on why "clang is building".
-fuse-ld= is not used with this method so some combinations of compiler
and linker are expected to fail.
A new 'make test-system-linker' target is added to see the logic results.
Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER. This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it. This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
Reviewed by: emaste (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15894
try to build them if MK_OPENSSL is unset.
Reviewed by: emaste imp kevans
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15211
changes for different branches. It's a bit rough right now,
but should be good enough for most people to try to use. It's
definitely 'tools' tree quality.
Cope for the fact that laoder.efi, not being boot1, doesn't read
/boot.config by setting boot_serial and force the serial console.
Also add sysctl so we can display the boot method.
Provide a variable, do_boot1_efi, if you want to use boot1 for
testing. But since it's transient, it's just a variable and not
available on the command line.
This extends the test suite to generate images for every combination of:
amd64: mbr/gpt geli/nogeli ufs/zfs legacy/uefi/both
Except for mbr+geli, which is not currently possible.
Reviewed by: imp (previous version)
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15846
128MiB still works for Legacy booting, however. Go ahead and do 256MiB
for all amd64 boxes, since the number of such boxes < 256MiB is
vanishingly small.
We want to use the versions of the bootcode we just built, rather than
ones from whatever happens to be in /boot on the test machine
These were incorrectly added by me in r334888
As of r306649 objcopy is always ELF Tool Chain's elfcopy; binutils
objcopy is never used.
PR: 229046
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
GNU grep as in actually in base does not have any translations support
compiled in, so no functionnality loss.
We do support 193 locales in base, we will never catch up on that number of
translation with bsd grep.
Removing NLS support make bsd grep consistent with the other binaries in base
which are not translated, and also reduce a little bit the code.
Reviewed by: kevans
Approved by: kevans
Discussed with: kevans @BSDCan
Differential Revision: https://reviews.freebsd.org/D15682
makefs disallows duplicate entries unless the -D option is specified.
Previously makeroot.sh enabled -D unless a filelist was provided via
the -f options. The filelist logic creates an mtree manifest from the
METALOG and the provided filelist by passing them through `sort -u`,
so duplicates were not expected. However, duplicates can still occur
when a directory appears in multiple packages -- for example,
./etc/pam.d type=dir uname=root gname=wheel mode=0755
./etc/pam.d type=dir mode=0755 tags=package=runtime
./etc/pam.d type=dir mode=0755 tags=package=at
./etc/pam.d type=dir mode=0755 tags=package=ftp
./etc/pam.d type=dir mode=0755 tags=package=telnet
For the purposes of makefs these directory entries are identical, but
are of course not identical for sort -u.
For now just leave the allow duplicates -D flag enabled.
PR: 228606
Sponsored by: The FreeBSD Foundation
When large SPDs are used, we face two problems:
- too many CPU cycles are spent during the linear searches in the SPD
for each packet
- too much contention on multi socket systems, since we use a single
shared lock.
Main changes:
- added the sysctl tree 'net.key.spdcache' to control the SPD cache
(disabled by default).
- cache the sp indexes that are used to perform SP lookups.
- use a range of dedicated mutexes to protect the cache lines.
Submitted by: Emeric Poupon <emeric.poupon@stormshield.eu>
Reviewed by: ae
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D15050
This driver was merged to HEAD one week prior to Exar publicly announcing they
had left the Ethernet market. It is not known to be used and has various code
quality issues spotted by Brooks and Hiren. Retire it in preparation for
FreeBSD 12.0.
Submitted by: kbowling
Reviewed by: brooks imp
Relnotes: yes
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15442
The Intel CPU "Platform Id" is a 3-bit integer reported by a given MSR.
Intel microcode updates have an 8-bit field to indicate Platform Id
compatibility - one bit in the mask for each of the possible Platform Id
values. To simplify interpretation, report the Platform Id mask also as
a list.
Intel now releases microcode updates in files named after
<family>-<model>-<stepping>. In some cases a single file may include
microcode for multiple Platform Ids for the same family, model, and
stepping. Our current microcode update tooling (/usr/sbin/cpucontrol)
only processes the first microcode update in the file.
This tool splits combined files into individual files with one microcode
update each, named as
<family>-<model>-<stepping>.<platform_id_mask>.
Adding this to tools/ for experimentation and testing. In the future
we'll want to have cpucontrol or other tooling work directly with the
Intel-provided microcode files.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15433
