FreeBSD and industry has been inconsistent in the use of UEFI and EFI.
They are essentially just different versions of the same specification
and are often used interchangeably. Make it easier for users to find
information by making efi(8) an alias for uefi(8).
Reported by: imp, jhb
- EFI support appeared in 5.0 for ia64
- arm64 UEFI support added in 11.0
The AUTHORS section included the folks responsible for the bulk of the
work to bring UEFI support to amd64, but missed those who did the
original work on ia64, the initial port to i386, the ports to arm64 and
arm, and have generally maintained and improved general UEFI support
since then. It's unwieldly to include everyone and would quickly become
outdated again anyhow, so just remove the AUTHORS section.
Reviewed by: manu
Discussed with: jhb
Differential Revision: https://reviews.freebsd.org/D14033
libregex is a regex(3) implementation intended to feature GNU extensions and
any other non-POSIX compliant extensions that are deemed worthy.
These extensions are separated out into a separate library for the sake of
not cluttering up libc further with them as well as not deteriorating the
speed (or lack thereof) of the libc implementation.
libregex is implemented as a build of the libc implementation with LIBREGEX
defined to distinguish this from a libc build. The reasons for
implementation like this are two-fold:
1.) Maintenance- This reduces the overhead induced by adding yet another
regex implementation to base.
2.) Ease of use- Flipping on GNU extensions will be as simple as linking
against libregex, and POSIX-compliant compilations can be guaranteed with a
REG_POSIX cflag that should be ignored by libc/regex and disables extensions
in libregex. It is also easier to keep REG_POSIX sane and POSIX pure when
implemented in this fashion.
Tests are added for future functionality, but left disconnected for the time
being while other testing is done.
Reviewed by: cem (previous version)
Differential Revision: https://reviews.freebsd.org/D12934
possible to change string and numeric vendor and product identifiers,
as well as anything else there might be to change for a particular
device side template, eg the MAC address.
Reviewed by: hselasky@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13920
This matches directory structure used commonly in Linux-land, and it's
cleaner than mixing overlays into the existing module paths. Overlays are
still mixed in by specifying fdt_overlays in loader.conf(5).
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13922
r314467 introduced hw.usb.wsp.enable_single_tap_clicks to enable/disable
single-tap left click behavior. Update the man page to reflect the new
sysctl.
PR: 196624
MFC after: 3 days
X-MFC-With: r314467
Attaching syscon_generic earlier than BUS_PASS_DEFAULT makes it more
difficult for specific syscon drivers to attach to the syscon node and to
get ordering right. Further discussion yielded the following set of
decisions:
- Move syscon_generic to BUS_PASS_DEFAULT
- If a platform needs a syscon with different attach order or probe
behavior, it should subclass syscon_generic and match on the SoC specific
compat string
- When we come across a need for a syscon that attaches earlier but only
specifies compatible = "syscon", we should create a syscon_exclusive driver
that provides generic access but probes earlier and only matches if "syscon"
is the only compatible. Such fdt nodes do exist in the wild right now, but
we don't really use them at the moment.
Additionally:
- Any syscon provider that has needs any more complex than a spinlock solely
for syscon access and a single memory resource should subclass syscon
directly rather than attempting to subclass syscon_generic or add complexity
to it. syscon_generic's attach/detach methods may be made public should the
need arise to subclass it with additional attach/detach behavior.
We introduce aw_syscon(4) that just subclasses syscon_generic but probes
earlier to meet our requirements for if_awg and implements #2 above for this
specific situation. It currently only matches a64/a83t/h3 since these are
the only platforms that really need it at the time being.
Discussed with: ian
Reviewed by: manu, andrew, bcr (manpages, content unchanged since review)
Differential Revision: https://reviews.freebsd.org/D13793
There's a report of some regression in ports. Revert for now for an
exp run for this change in isolation (previous lld exp run also included
switching the linker used for ports to lld).
Also revert the src.conf.5 regeneration in r327824.
Reported by: antoine
Sponsored by: The FreeBSD Foundation
Another solution would be to extend the Makefile.sys.inc idea, or a .no_obj
file, to more places but I would rather keep that limited to the top-level
build for now to not impact performance (statting a file in every make call)
or to bring unintended side-effects.
Reported by: jhb, imp
Sponsored by: Dell EMC Isilon
Akin to r327783 for amd64. lld has been usable for amd64 for quite some
time, but a couple of issues remained that affected i386. These were
recently addressed upstream in lld and merged into FreeBSD (r326831,
r326879, r326897, r326957), so we can now use ld.lld on i386 as well.
Similarly to amd64 this change enables lld only as the bootstrap linker
(used to link the kernel and userland libraries and executables), while
GNU ld.bfd is still installed as /usr/bin/ld and used for ports builds.
The ports collection is essentially ready to use lld as the system
linker for amd64, but many ports still have trouble with lld on i386,
because lld defaults to -ztext, disallowing relocations against readonly
segments. Thus switching the system linker (WITH_LLD_IS_LD) will happen
later on a per-arch basis.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Additionally, move the overflow check logic out to WOULD_OVERFLOW() for
consumers to have a common means of testing for overflowing allocations.
WOULD_OVERFLOW() should be a secondary check -- on 64-bit platforms, just
because an allocation won't overflow size_t does not mean it is a sane size
to request. Callers should be imposing reasonable allocation limits far,
far, below overflow.
Discussed with: emaste, jhb, kp
Sponsored by: Dell EMC Isilon
(I missed the Reviewed by and review link from r327783.)
Reviewed by: brooks, dim, bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13827
For some time we have been planning to migrate to LLVM's lld linker.
Having a man page was the last blocking issue for using ld.lld to link
the base system kernel + userland, now addressed by r327770. Link the
kernel and userland libraries and binaries with ld.lld by default, for
additional test coverage.
This has been a long time in the making. On 2013-04-13 I submitted an
upstream tracking issue in LLVM PR 23214: [META] Using LLD as FreeBSD's
system linker. Since then 85 individual issues were identified, and
submitted as dependencies. These have been addressed along with two
and a half years of other lld development and improvement.
I'd like to express deep gratitude to upstream lld developers Rui
Ueyama, Rafael Espindola, George Rimar and Davide Italiano. They put in
substantial effort in addressing the issues we found affecting
FreeBSD/amd64.
To revert to using ld.bfd as the bootstrap linker, in /etc/src.conf set
WITHOUT_LLD_BOOTSTRAP=yes
If you need to set this, please follow up with a PR or post to the
freebsd-toolchain mailing list explaining how default WITH_LLD_BOOTSTRAP
failed for your use case.
Note that GNU ld.bfd is still installed as /usr/bin/ld, and will still
be used for linking ports. ld.lld can be installed as /usr/bin/ld by
setting in /etc/src.conf
WITH_LLD_IS_LLD=yes
A followup commit will set WITH_LLD_IS_LD by default, possibly after
Clang/LLVM/lld 6.0 is merged to FreeBSD.
Release notes: Yes
Sponsored by: The FreeBSD Foundation
We currently use a set of subroutines in kern_gzio.c to perform
compression of user and kernel core dumps. In the interest of adding
support for other compression algorithms (zstd) in this role without
complicating the API consumers, add a simple compressor API which can be
used to select an algorithm.
Also change the (non-default) GZIO kernel option to not enable
compressed user cores by default. It's not clear that such a default
would be desirable with support for multiple algorithms implemented,
and it's inconsistent in that it isn't applied to kernel dumps.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D13632
Similar to calloc() the mallocarray() function checks for integer
overflows before allocating memory.
It does not zero memory, unless the M_ZERO flag is set.
Reviewed by: pfg, vangyzen (previous version), imp (previous version)
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D13766
The sid controller on the H3 is generally identical in location, size, and
efuse offset to the a64 and the a83t. The main difference is that the H3 has
a silicon bug that sometimes causes the rootkey (at least) to be garbled
unless first read by the prctl registers.
This device is currently not in our DTS and, as of now, is not yet present
in mainline Linux DTS.
Tested on: OrangePi One
I will be moving on to other life commitments this year and will not have
the time to support contributions as a ports committer, if able, until life
settles at the end of the year.
Discussed with: portmgr
Enable the hardclock-based watchdog previously conditional on the
SW_WATCHDOG option whenever hardware watchdogs are not found, and
watchdogd attempts to enable the watchdog. The SW_WATCHDOG option
still causes the sofware watchdog to be enabled even if there is a
hardware watchdog. This does not change the other software-based
watchdog enabled by the --softtimeout option to watchdogd.
Note that the code to reprime the watchdog during kernel core dumps is
no longer conditional on SW_WATCHDOG. I think this was previously a bug.
Reviewed by: imp alfred bjk
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D13713
This copies changes from NetBSD into FreeBSD's man page. I compared the
proposed changes against FreeBSD headers and modified them to match.
PR: 214602
Submitted by: fehmi noyan isi <fnoyanisi@yahoo.com>
Introduce new set of loader tunables kern.vt.color.N.rgb, where N is a
number from 0 to 15. The value is either comma-separated list decimal
numbers ranging from 0 to 255 that represent values of red, green, and
blue components respectively (i.e. "128,128,128") or 6-digit hex triplet
commonly used to represent colors in HTML or xterm settings (i.e. #808080)
Each tunable overrides one of the 16 hardcoded palette codes and can be set
in loader.conf(5)
Reviewed by: bcr(docs), jilles, manu, ray
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13645
A comment in Makefile.inc1 has long stated that LOCAL_DIRS are built last,
after the base system. Incremental improvements in parallel building over
the years have led to LOCAL_DIRS being built in parallel with base system
directories. This change allows the .WAIT directive to appear in LOCAL_DIRS
and LOCAL_LIB_DIRS lists to give the user some control over parallel
building of local additions.
Differential Revision: https://reviews.freebsd.org/D13622
This adds HardenedBSD which is a pseudo-fork of FreeBSD. It hasn't had a
release yet, but does does have active users and a community. As such
document it as a branch off of FreeBSD-stable. Ideally this adds enough
space so that future releases are easy enough to add.
filesystem larger than about 50-55 MiB.
The description of VM_KMEM_SIZE_SCALE is roughly as hand-wavy as my
understanding of the option, but at least mentioning that it's a factor
and giving an empirical datapoint that works will give folks some idea
of what to tweak if they have problems.
new clang 6.0.0 -Wtautological-constant-compare warning to the WARNS <=
6 level. (This warning is still being worked on upstream to reduce
false positives, but it is currently still too trigger happy.)
MD_READONLY flag for the md device automatically instantiated during
kernel init for an mdroot filesystem.
Note that there is specifically and by design no tunable or sysctl
control over this feature. Without this option, you already have control
over whether the mdroot fs is writeable using vfs.root.mountfrom.options
from loader(8), the root_rw_mount rcvar, and by using "mount -u[rw] /"
or equivelent on the fly. This option is being added to provide a way
to make the mdroot fs truly immutable before userland code begins running.
Differential Revision: https://reviews.freebsd.org/D13411
Email address has changed, uses consistent name (Matthew, not Matt)
Reported by: Matthew Macy <mmacy@mattmacy.io>
Differential Revision: https://reviews.freebsd.org/D13537
Add atomic_load_<type> and atomic_store_<type>, and explain why they
exist.
Define the synchronizes-with relationship and its effects.
Reorder and revise some of the existing text. For example, more
precisely describe when ordinary accesses are atomic.
Reviewed by: jhb, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13522
temporary workaround. This fixes zfs booting generally, but breaks all
GELI booting by default. Add note to UPDATING to this effect. When the
GELI issues are resolved, this will be reverted.
the expected default board_vendor value on MIPS SoCs.
This is required by bwn(4) to differentiate between single-band and
dual-band device variants that otherwise share a common chip ID.
Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation
rc.conf(5) documents the gifconfig_<interface> keyword, which is
no longer implemented. Document the replacement, which works with
cloned_interfaces as well.
Reviewed by: dab
Group Reviwers: manpages
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D13130
Several checks assume .CURDIR is resolved, such as for determining RELDIR from
SRCTOP/.CURDIR. If -C is used then the path is no longer resolved like it was
before which is problematic for symlinked source trees. A similar change was
also made to ports post bmake-20170301.
This fixes 'make -C <symlinked path> buildworld' using the wrong OBJDIR.
Reported by: rstone
Sponsored by: Dell EMC
This will cause an error if the wanted OBJDIR is not writable. Previously it
would cause the files to generate to the source tree. This was too obscure and
things like buildworld really expect a proper OBJDIR layout.
Sponsored by: Dell EMC
