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.
