This enables virtio modules on PowerPC* target.
On PowerPC64, drivers are also kernel builtin.
QEMU currently needs to be patched to in order to work on LE hosts due to known
issue affecting pre-1.0 (legacy) virtio drivers.
The patch was submitted to QEMU mail list by @afscoelho_gmail.com, available at
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg01496.html
Submitted by: Alfredo Dal'Ava Junior <alfredo.junior@eldorado.org.br>
Reviewed by: luporl
Differential Revision: https://reviews.freebsd.org/D22833
arichardson has an actual fix for the same issue that this was working
around; given that we don't build with llvm today, go ahead and revert the
workaround in advance.
This provides a specific pointer for users of tap(4) to understand why their
interfaces are losing their addresses, and specifically how to workaround
this if they need different behavior.
This manpage received a .Dd bump earlier today in r35688, so no bump occurs
this time.
Submitted by: sigsys@gmail.com (via IRC)
Explicitly setting WITHOUT_KERBEROS implies WITHOUT_KERBEROS_SUPPORT,
but previously other cases that forced KERBEROS off (such as
WITHOUT_CRYPT) did not also set KERBEROS_SUPPORT off. Because the
_SUPPORT dependent options (KERBEROS/KERBEROS_SUPPORT) are processed
before other dependencies (CRYPT/KERBEROS) it's not easy to make this
happen automatically. Instead just explicitly set KERBEROS_SUPPORT
off where we set KERBEROS off.
Reported by: Michael Dexter's Build Option Survey run
Step 5 (Update Mentor and Mentee Information) from Commiters guide.
I also alphababetize mentees from tcberner.
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D23125
hard use floating point hardware, pass registers to functions in
floating point registers.
softfp use floating point hardware, but pass registers to functions
in integer registers.
soft do floating point calcuations without using floating point
hardware. Pass arguments in integer registers.
FreeBSD 11 and newer assumes hard. 10 and earlier assumed softfp. We have no
real support, at the moment, for soft. It's untested, though, if softfp still
works.
Add a note here since this is a whack-a-doodle combination relative to all other
platforms.
softfp is likely to go away in the future because it was retained for people
using FreeBSD 10 + armv6 needing to transition more slowly from softfp -> hard
than the project. It likely is no longer needed, and may be getting in the
way of people needing 'soft' support.
It's not immediately clear by what mechanism loader(8) will be loading the
preloaded file. Specifically name-drop loader.conf(5) with a pointer to the
module loading section and a description of what the 'name' should look
like, because that certainly isn't clear from the loader.conf(5) standpoint.
The default loader.conf already has a pointer to md(4) where it appears and
the reference to loader.conf in the new version of this manpage should make
it more clear that this is where one should look for information.
Reported by: swills
Reviewed by: swills, manpages (bcr)
With revision by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D22844
- Garbage collect UMA_ZONE_PAGEABLE & UMA_ZONE_STATIC.
- Move flag VTOSLAB from public to private.
- Introduce public NOTPAGE flag and make HASH private.
- Introduce public NOTOUCH flag and make OFFPAGE private.
- Update man page.
The net effect of this should be to make the contract with clients more
clear. Clients should choose constraints, UMA will figure out how to
implement them. This also breaks the confusing double meaning of
OFFPAGE.
Reviewed by: jeff, markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D23016
Only sparc64 did not enable LLVM_LIBUNWIND. After r356513 LLVM_LIBUNWIND
should at least build on sparc64. The old DWARF unwinder will be removed
along with GCC 4.2.1 in the near future, so switch sparc64 to use LLVM's
unwinder in advance of the removal. Someone with access to the obsolete
sparc64 hardware supported by FreeBSD will have to test, and investigate
any failures. I will gladly help, but I don't have any suitable hardware
myself.
PR: 233405
bsd.cpu.mk is included by bsd.init.mk before bsd.linker.mk, so it
was always setting the flag since LINKER_FEATURES wasn't defined.
Reported by: mhorne
Reviewed by: imp, mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23076
- Enable clang and lld as system toolchains.
- Don't use external GCC for universe by default.
- Re-enable riscv64sf since it builds fine with clang + lld.
Reviewed by: emaste, mhorne
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23089
This allows cheapest DRAM-less NVMe SSDs to use some of host RAM (about
1MB per 1GB on the devices I have) for its metadata cache, significantly
improving random I/O performance. Device reports minimal and preferable
size of the buffer. The code limits it to 1% of physical RAM by default.
If the buffer can not be allocated or below minimal size, the device will
just have to work without it.
MFC after: 2 weeks
Relnotes: yes
Sponsored by: iXsystems, Inc.
This re-enables building the googletest suite by default on mips and instead
specifically doesn't build fusefs tests for mips+clang builds. clang will
easily spent >= 1.5 hours compiling a single file due to a bug in
optimization (see LLVM PR 43263), so turn these off for now while that's
hashed out.
GCC builds are unaffected and build the fusefs tests as-is. Clang builds
only happen by early adopters attempting to hash out the remaining issues.
The comment has been updated to reflect its new position and use less strong
wording about imposing on people.
Discussed with: ngie, asomers
Reviewed by: ngie
Extend r356379 to include 32-bit mips and sparc64. Using a decade-old
binutils linker with a contemporary compiler (either Clang or GCC) is
a combination unlikely to be used by anyone else, and it's not going
to be a good use of our time investigating and addressing any issues
that arise. Expect that all architectures newly migrated to external
GCC will also use external binutils.
After GCC was disabled by default in r356367, mips and sparc64 started
relying external GCC. However, the in-tree Binutils ld 2.17.50 is not
compatible with GCC for some mips64 targets, so turn off
BINUTILS_BOOTSTRAP and rely on external binutils (linker) as well.
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
Use "mipsel" instead of "mips" as the 32-bit MACHINE_ARCH when
building lib32 for little-endian 64-bit MIPS targets. This fixes an
error where some objects were compiled as LE and others compiled as BE
causing a link error for rtld32.
Reviewed by: emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23028
More MACHINE_CPUARCH/MACHINE_ARCH cases enable these options than
disable them, and several of them have work in progress to switch over.
Thus, invert the sense of the test and list cases not using LLD as the
exceptions.
There were a few special cases for arm v5, such as disabling LLDB due to
the lack of 64-bit atomic operations. Now that arm has been retired (as
of r356263) we can simplify the options logic somewhat.
An i2c bus can be divided into segments which can be selectively connected
and disconnected from the main bus. This is usually done to enable using
multiple slave devices having the same address, by isolating the devices
onto separate bus segments, only one of which is connected to the main bus
at once.
There are several types of i2c bus muxes, which break down into two general
categories...
- Muxes which are themselves i2c slaves. These devices respond to i2c
commands on their upstream bus, and based on those commands, connect
various downstream buses to the upstream. In newbus terms, they are both
a child of an iicbus and the parent of one or more iicbus instances.
- Muxes which are not i2c devices themselves. Such devices are part of the
i2c bus electrically, but in newbus terms their parent is some other
bus. The association with the upstream bus must be established by
separate metadata (such as FDT data).
In both cases, the mux driver has one or more iicbus child instances
representing the downstream buses. The mux driver implements the iicbus_if
interface, as if it were an iichb host bridge/i2c controller driver. It
services the IO requests sent to it by forwarding them to the iicbus
instance representing the upstream bus, after electrically connecting the
upstream bus to the downstream bus that hosts the i2c slave device which
made the IO request.
The net effect is automatic mux switching which is transparent to slaves on
the downstream buses. They just do i2c IO they way they normally do, and the
bus is electrically connected for the duration of the IO and then idled when
it is complete.
The existing iicbus_if callback() method is enhanced so that the parameter
passed to it can be a struct which contains a device_t for the requesting
bus and slave devices. This change is done by adding a flag that indicates
the extra values are present, and making the flags field the first field of
a new args struct. If the flag is set, the iichb or mux driver can recast
the pointer-to-flags into a pointer-to-struct and access the extra
fields. Thus abi compatibility with older drivers is retained (but a mux
cannot exist on the bus with the older iicbus driver in use.)
A new set of core support routines exists in iicbus.c. This code will help
implement mux drivers for any type of mux hardware by supplying all the
boilerplate code that forwards IO requests upstream. It also has code for
parsing metadata and instantiating the child iicbus instances based on it.
Two new hardware mux drivers are added. The ltc430x driver supports the
LTC4305/4306 mux chips which are controlled via i2c commands. The
iic_gpiomux driver supports any mux hardware which is controlled by
manipulating the state of one or more gpio pins. Test Plan
Tested locally using a variety of mux'd bus configurations involving both
ltc4305 and a homebrew gpio-controlled mux. Tested configurations included
cascaded muxes (unlikely in the real world, but useful to prove that 'it all
just works' in terms of the automatic switching and upstream forwarding of
IO requests).
- Drop mention of _LP64. FreeBSD's source generally uses __LP64__
instead of _LP64, and the relevant macros are better covered in the
"Predefined Macros" section.
- Fix a noun/verb disagreement.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22975
- Add missing .Pp after the end of some lists so that there is a blank
line before the subsequent paragraph.
- Use a more typical '-tag' bullet list of the make variable descriptions
at the end. This adds separation between bullets and is the formatting
typically used in manpages for this sort of list.
