- zfs depends on the crypto module, not cryptodev, and most arm64 kernel
configs include std.dev, which includes "device crypto" anyway.
- This config works around a problem with kldxref lacking cross-target
support, but that has since been fixed.
- Loading cryptodev creates /dev/crypto, which gives unprivileged users
access to the kernel's opencrypto framework. Very few applications
need it, so we're needlessly increasing the kernel's surface area.
Thus, stop auto-loading cryptodev.
Reviewed by: kevans, allanjude, des
Differential Revision: https://reviews.freebsd.org/D45127
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d088290
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
Rename `M_PRINT` and `M_UPDATE` to `M_SHOW` and `M_MODIFY` to match the
names of the commands they represent. No functional change intended.
MFC after: 3 days
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D45096
This function is documented to be gone in after 11. Time to remove this
compat shim.
PR: 275296
Reviewed by: jrm (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D44796
This daemon can operate as a purely userspace controller exporting one
or more simulated RAM disks or local block devices as NVMe namespaces
to a remote host. In this case the daemon provides a discovery
controller with a single entry for an I/O controller.
nvmfd can also offload I/O controller queue pairs to the nvmft.ko
in-kernel Fabrics controller when -K is passed. In this mode, nvmfd
still accepts connections and performs initial transport-specific
negotitation in userland. The daemon still provides a userspace-only
discovery controller with a single entry for an I/O controller.
However, queue pairs for the I/O controller are handed off to the CTL
NVMF frontend.
Eventually ctld(8) should be refactored to to provide an abstraction
for the frontend protocol and the discovery and the kernel mode of
this daemon should be merged into ctld(8). At that point this daemon
can be moved to tools/tools/nvmf as a debugging tool (mostly as sample
code for a userspace controller using libnvmf).
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44731
Change the first argument of ctl_scsi_path_string to be the embedded
header structure instead of the union. Currently union ctl_io and
struct ctl_scsiio have the same alignment, but this changes on i386 if
a new union member is added that contains a uint64_t member (such as
an embedded struct nvme_command for NVMeoF). In that case, union
ctl_io requires stronger alignment, so the upcast from struct
ctl_scsiio to union ctl_io in ctl_scsi_sense_sbuf raises an increasing
alignment warning on i386.
Avoid the warning by passing struct ctl_io_hdr as the first argument
to ctl_scsi_path_string instead.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44716
Currently, lock of uart in bhyve is placed in frontend. There are some
problems about it:
1. If every frontend should has a lock, why not move it inside backend
as they all have same uart_softc.
2. If backend needs to modify the information of uart after initialize,
it will be impossible as backend cannot use lock. For example, if we
want implement a telnet support for uart in backend, It should wait
for connection when initialize. After some remote process connect it,
it needs to modify rfd and wfd in backend.
So I decide to move it to backend.
Reviewed by: corvink, jhb, markj
Differential Revision: https://reviews.freebsd.org/D44947
For now this implementation doesn't provide any machine dependent
functionality on arm64, but it's enough to be able to reset and destroy
VMs.
Reviewed by: jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44932
Move MD code into a separate directory and add a simple interface which
lets the MD bits register options and handle them.
No functional change intended.
Reviewed by: jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44932
This was prompted by noticing that '/var/db/portsnap' still exists on
newly-installed machines.
With this change, all mentions of portsnap(8) in the tree are gone,
except for the historical note in the AUTHORS section of manpage
phttpget(8).
locate(1) will thus start indexing again '/var/db/portsnap' on machines
where this directory still exists, which may be a good way to push
administrators to delete it.
Reviewed by: cperciva
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45023
Introduce pfctl_get_status_h() because we need the pfctl_handle. In this variant
use netlink to obtain the information.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Just make "restore_file" a global variable so that it can be set by the
MD option handler.
Reviewed by: corvink
Reported by: bdrewery
Fixes: 981f9f7495 ("bhyve: Push option parsing down into bhyverun_machdep.c")
Differential Revision: https://reviews.freebsd.org/D44974
Move auditing runtime (auditd, etc.) into the new FreeBSD-audit package.
Also move the runtime OpenBSM manual pages from libbsm into auditd so
they get installed with the right package.
Add an UPDATING entry noting the new packages.
Reviewed by: imp, manu
Pull Request: https://github.com/freebsd/freebsd-src/pull/1197
bhyve's man page is a very long block of text that has grown to
proportions that make it hard to read. In particular, the level of
nesting of various content means man can no longer render the text in a
user-friendly way.
To remedy this:
- move the -s argument documentation into a separate section and
reformat the various arguments so they are consistent
- add documentation on how to use the -o config.dump feature
- make the listing of various arguments more consistent
- consolidated duplicate listings of TPM backends
- add an example for the config.dump feature
- fix various formatting inconsistencies.
Reviewed by: emaste, imp, jrm, Pau Amma <pauamma@gundo.com>, rgrimes
Differential Revision: https://reviews.freebsd.org/D43940
pkg_add has been gone since 2013(?). Refer to pkg(8) instead.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D44946
- Mention the options that are amd64-only.
- Provide a minimal example for booting an arm64 guest.
Reviewed by: corvink
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44738
It is a no-op on amd64 now and is not implemented on arm64, so let's
remove mention of it altogether so as to reduce confusion for arm64
users.
Reviewed by: corvink, jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44737
1. Currently, distfetch checks environment variables existence
when it will use them or in a case (in chdir()) it doesn't check
at all. As they are necessary to set before doing anything with
it, check them, if they set or not, before proceeding any further.
This also avoids extra cleaning when that environment variable
isn't set.
2. Handle memory allocation error in malloc(PATH_MAX) and replace
(sizeof const char *) with (sizeof char *). Both are similar and
const doesn't have a size.
3. Indent the error message a bit in chdir().
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1071
Reported by: Jose Luis Duran <jlduran@gmail.com>
Fixes: b37333899b
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44871
Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA
(i.e., dma) if mailer.conf couldn't be opened for any reason, including
transient errors like ENFILE. This behaviour is undesirable, because if
the administrator has configured a different MTA in mailer.conf, they
almost certainly don't want mailwrapper to unpredictably fall back to
the compiled-in default; and in any case, the default MTA is probably
not running, meaning the mail may be queued and then never delivered,
which is worse than not accepting it to begin with.
Change this behaviour depending on why mailer.conf can't be opened:
- If it doesn't exist, keep the existing behaviour of falling back to
the default MTA, on the assumption that this is a reasonable default
if mailer.conf hasn't been configured at all.
- If it cannot be opened for any other reason, do not invoke an MTA and
instead return an error to the caller.
PR: 25218
Reviewed by: imp, emaste, markj
Pull Request: https://github.com/freebsd/freebsd-src/pull/969
Most importantly:
* Make local variables local.
* Use `$()` instead of backticks.
* Avoid unsafe use of `-a` and `-o` operators in `test` expressions.
* Remove a hack intended to ease the transition from Perl 22 years ago.
MFC after: 1 week
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44863
"bsdbox --list" will print all tools in the binary, one per line. The
main use case for this is to make it easier to create links:
for t in $(bsdbox --list); do
ln -s bsdbox $t
done
The name --list was taken from busybox.
This just adds a new "program" with the name "--list". I don't think we
need to do real argument parsing here, and this is also how busybox does
it.
An additional minor change is that just "bsdbox" will no longer print
the binary name itself ("bsdbox" in this case). Before it would do:
% bsdbox
usage: boxlike <prog> <args> ..., where <prog> is one of:
cp ls mv bsdbox
And now just:
% bsdbox
usage: boxlike <prog> <args> ..., where <prog> is one of:
cp ls mv
And just "bsdbox" will also exit with code 0 (and print to stdout)
rather than exit with 0 and print to stderr
Example output:
% ./bsdbox
usage: bsdbox program [args ...]
bsdbox --list
program [args ...]
bsdbox combines several programs in one executable. Create a link to this
executable with the program name to run that program, or give the program
name as the first argument.
Currently defined programs:
true false tail head uname
% ./bsdbox --list
true
false
tail
head
uname
% ./bsdbox uname -a
FreeBSD freebsd 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
% ln -s bsdbox uname
% ./uname -a
FreeBSD freebsd 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
Pull Request: https://github.com/freebsd/freebsd-src/pull/894
Signed-off-by: Martin Tournoij <martin@arp242.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/894
If not, then in general the entire filesystem containing the exported
directory is accessiable. This may be surprising, so try to make it
more clear.
Reviewed by: rmacklem, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44614
Mergemaster has been deprecated for quite some time, but was not
removed prior to FreeBSD 14.0. Update the deprecation notice in the man
page to reflect this.
PR: 274967
Reported by: naddy
Sponsored by: The FreeBSD Foundation
During the install process tzsetup asks a question like
Does the abbreviation `EDT' look reasonable?
The installer asks lots of questions, some that relate to the previous
screen or topic and some that do not. A new user installed FreeBSD for
the first time and was confused by this question, not realizing that it
was asking whether the abbreviation is correct for the selected
timezone.
Reviewed by: bapt, brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44500
People get confused when some software (VirtualBox, etc) does not work as
expected (or at all) after a major upgrade.
We have a nice way to deal with this when using sources, namely including
PORTS_MODULES in /etc/make.conf, but we lack something similar for binary
updates.
This patch retrieves a list of kernel modules installed from packages and
advises the user to recompile from ports to avoid problems.
Approved by: zlei@
Differential Revision: https://reviews.freebsd.org/D39695
If we're doing restarts, then we must supervise -- the 'R' case simply
got missed.
PR: 278342
Fixes: f907027b49 ("daemon: set supervise_enabled during [..]")
The __builtin_unreachable macro provided by Clang and GCC is a hint to
the compiler used for optimization. The programs work fine even if the
compiler doesn't support it. The sys/cdefs.h has had __unreachable for
9 years (commit 732b31de5d). It expands
to the builtin if it is available. In the rare case that it is
unsupported it expands to a null statement so compilation does not
fail.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed by: imp, freebsd@igalic.co
Pull Request: https://github.com/freebsd/freebsd-src/pull/1117
The __builtin_unreachable macro provided by Clang and GCC is a hint to
the compiler used for optimization. The programs work fine even if the
compiler doesn't support it. The sys/cdefs.h has had __unreachable for
9 years (commit 732b31de5d). It expands
to the builtin if it is available. In the rare case that it is
unsupported it expands to a null statement so compilation does not
fail.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed by: imp, freebsd@igalic.co
Pull Request: https://github.com/freebsd/freebsd-src/pull/1117
1. Both trackbuf and vrfybuf are initialized to
zero (NULL). While it's okay to initialize pointers
to zero, to keep consistency, as they're explicitly
pointers, it's better to just use NULL ((void *)0)
instead of 0 (both are equivalent to the compilers).
2. Call free() for both trackbuf and vrfybuf after
their job has been done.
3. Remove the register keyword. Compilers generally
ignore this keyword (except for very very old compilers
and CPUs).
4. Remove the ctype.h header. It's not being used
anywhere in the file.
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1059
On systems utilizing ZFS, default to creating a ZFS dataset for a new
user's home directory if the parent directory resides on a ZFS dataset.
Add a flag that disables this behavior if the administrator explicitly
does not want it.
If run during installation from within a chroot, set mountpoint to legacy
after dataset creation and mount directly into the chroot. Then umount
and reset the mountpoint to inherit from parent.
Also support ZFS default encryption on user's home directory.
Feedback by: delphij
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/881
Unlike amd64's, this RTC is implemented entirely in userspace. This is
the same RTC as is provided by QEMU's virt machine.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This clock will also be used by the PL031 RTC (rather than defining
redundant per-device clocks).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This is supposed to combine with the memory range to make one contiguous
block, as is laid out in the FDT, so make this match what the OS is told
and thus actually configures.
Also drop the confusing leading zero from all three of these constants
that is making these 9 rather than 8 hex digits long (as one would
expect for a 32-bit address).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This allows us to remove various #ifdef hacks and enable building more
PCI devices.
Note that a hole is left in the interrupt mapping for the RTC rather
than having the two core devices straddle the PCIe interrupts. QEMU's
virt machine also takes this approach.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
After a couple of attempts I think this is the cleanest approach despite
the expense of some code duplication. Quite a few of the single-letter
bhyve options are x86-specific.
I think that going forward we should strongly discourage the addition of
new options and instead configure guests using the more general
configuration file syntax.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41753
A FreeBSD guest won't make use of this support and pci_lintr_* is not
implemented on arm64. Simply make pci_lintr_*() calls amd64-specific
for now.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41741
- The extended config space and BAR ranges are listed in the FDT.
- Avoid referencing I/O ports in ACPI tables. Currently the arm64 port
does not support ACPI in any case.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41739
Some required kernel functionality is not yet implemented.
For now this means that one cannot specify host PCI register values, but
that functionality is only used by amd64-specific device models for now.
Note that this limitation is rather artificial; it arises only because
pci_host_read_config() lives in pci_passthru.c.
Reviewed by: corvink, andrew, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41738
This reduces the coupling between libvmmapi (which creates the highmem
segment) and bhyve, in preparation for the arm64 port.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40992
fdt.c provides some basic routines which let platform initialization
code build the FDT that gets passed into the guest. For now this is not
very generic; we declare info about CPUs, memory, a single UART
(specified by -o console), a PCIe controller (used for virtio devices),
an interrupt controller and the platform timer.
Co-authored-by: andrew
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40996
The arm64 port currently does not support ACPI, it instead builds up an
FDT which is exported to the guest. This mechanism will not be used on
amd64 but isn't really arm64-specific either, so provide an opt-in
mechanism to link libfdt.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40995
This will be use for arm64 guests, instead of the existing ns16550 UART
model.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40997
As mentioned in zpoolprops(7), on some SSDs, it may not be desirable to
use ZFS autotrim because a large number of trim requests can degrade
disk performance; instead, the pool should be manually trimmed at
regular intervals.
Add a new daily periodic script for this purpose, 801.trim-zfs. If
enabled (daily_trim_zfs_enable=YES; the default is NO), it will run a
'zpool trim' operation on all online pools, or on the pools listed in
'daily_trim_zfs_pools'.
The trim is not started if the pool is degraded (which matches the
behaviour of the existing 800.scrub-zfs script) or if a trim is already
running on that pool. Having autotrim enabled does not inhibit the
periodic trim; it's sometimes desirable to run periodic trims even with
autotrim enabled, because autotrim can elide trims for very small
regions.
PR: 275965
MFC after: 1 week
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/956
Commit fefb7c399b added warning messages noting
that administrative controls that exported directories
that are not local server file system mount points actually
export the entire local server file system.
This commit also added a new command line option "-A' that
silences these warnings.
This patch documents the new "-A' mountd option.
This is a content change.
Reviewed by: markj, pauamma_gundo.com (manpages)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44692
The usage text had fallen out of sync with the actually available
options. Rather than keep them in sync by hand, just generate usage from
the available options.
Signed-off-by: Rob Norris <robn@despairlabs.com>
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44641
and disable warnings about unused function args coming from the vendor
acpi headers.
Reviewed by: markj
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44634
The field comes from the ACPI NFIT table and must be already properly
aligned by BIOS (at least so is written in the spec).
Reviewed by: markj
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44634
