For tools that uses bhyve such like libvirt, it is important to be able to
probe what features are supported by the given bhyve binary.
To give more context, libvirt probes bhyve's capabilities in a not very
effective way:
- Running 'bhyve -h' and parsing output.
- To detect devices, it runs 'bhyve -s 0,dev' for every each device and
parses error output to identify if the device is supported or not.
PR: 2101111
Submitted by: novel
MFC after: 2 weeks
Relnotes: yes
Sponsored by: iXsystems Inc.
2^32 bps or greater to be used. Prior to this, bandwidth parameters
would simply wrap at the 2^32 boundary. The computations in the HFSC
scheduler and token bucket regulator have been modified to operate
correctly up to at least 100 Gbps. No other algorithms have been
examined or modified for correct operation above 2^32 bps (some may
have existing computation resolution or overflow issues at rates below
that threshold). pfctl(8) will now limit non-HFSC bandwidth
parameters to 2^32 - 1 before passing them to the kernel.
The extensions to the pf(4) ioctl interface have been made in a
backwards-compatible way by versioning affected data structures,
supporting all versions in the kernel, and implementing macros that
will cause existing code that consumes that interface to use version 0
without source modifications. If version 0 consumers of the interface
are used against a new kernel that has had bandwidth parameters of
2^32 or greater configured by updated tools, such bandwidth parameters
will be reported as 2^32 - 1 bps by those old consumers.
All in-tree consumers of the pf(4) interface have been updated. To
update out-of-tree consumers to the latest version of the interface,
define PFIOC_USE_LATEST ahead of any includes and use the code of
pfctl(8) as a guide for the ioctls of interest.
PR: 211730
Reviewed by: jmallett, kp, loos
MFC after: 2 weeks
Relnotes: yes
Sponsored by: RG Nets
Differential Revision: https://reviews.freebsd.org/D16782
Upcoming Ethernet hardware will support new media types that aren't in the kernel
yet, so they are added here. These mostly include new 25G/50G/100G media types;
and this commit introduces new 200G/400G speeds and media.
Reviewed by: hselasky@, jhb@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D16731
The error handling got lost during r334810, while according to the report
error there may happen in case of dataset being over quota. In such case
just leave the node in the unlinked list to be freed sometimes later.
PR: 229887
Sponsored by: iXsystems, Inc.
r334810 introduced zfs_unlinked_drain() dispatch to taskqueue on every
deletion of a file with extended attributes. Using system_taskq for that
with its multiple threads in case of multiple files deletion caused all
available CPU threads to uselessly spin on busy locks, completely blocking
the system.
Use of single dedicated taskqueue is the only easy solution I've found,
while in would be great if we could specify that some task should be
executed only once at a time, but never in parallel, while many tasks
could use different threads same time.
Sponsored by: iXsystems, Inc.
This is related to pkgbase as it uses CONFS to properly tag these as config
files.
Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16785
are fully debugged. With these options off, the unified "loader"
binary for sparc64 works to boot a kernel from ZFS.
Submitted by: kevans
Reviewed by: imp kevans
operation of "loader". The dramatic increase in size of
SPA_MAXBLOCKSIZE in r304321 causes the heap space to be exhausted,
so malloc() fails, ultimately leading to a memcpy() with a
destination of 0x0.
MFC after: 3 days
A similar note is already present in the description of the
ntpd_sync_on_start variable.
This patch adds a note to the description of the ntpdate_enable variable.
This way it would be easier to spot. Otherwise a user might skip the part
of the manual describing ntpd_sync_on_start if they stop reading after
learning about ntpdate_enable.
Reviewed by: bcr
Approved by: mat (mentor)
Differential Revision: https://reviews.freebsd.org/D16519
PR#230752 shows a panic where an nfsd thread tries to do soconnect() on
the AF_LOCAL socket used by the nfsuserd while already holding an
exclusive lock on it. I am not 100% sure how this happens, but since an
AF_LOCAL socket is in the file system namespace it is conceivable that it
could lock it and then attempt an upcall to the nfsuserd.
However, reverting r320757 stops the nfsuserd from using an AF_LOCAL
socket, so it should avoid any such panic().
r320757 did fix a problem with running the nfsuserd when jails were
enabled, but that can be dealt with less elegantly by allowing the
use of an alternate address instead of 127.0.0.1.
The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls
before the nfsd thread processes the RPC, so I think it should not
be suseptible to this problem.
PR: 230752
This way the target fails if unifdef doesn't exist or doesn't modify the
file instead of just generating an empty .c file.
I found this while building without inherited $PATH (D16815)
Approved By: jhb (mentor)
The current invocation of unifdef causes the build to fail when using a shell
with -o pipefail on by default since unifdef will return a non-zero exit status
if it changes something. The only thing this call to unifdef does is remove 5
lines that will be ignored by the compiler anyway. Furthermore, it is the only
make rule in the source tree that requires unifdef. Removing this call also
makes it slightly easier to build without inhering $PATH (D16815) since we
don't need unifdef anymore.
I also noticed that the sed call to replace the include guard has been broken
for over 10 years since the import of expat 2.0.1 changed it from
`XmlParse_INCLUDED` to `Expat_INCLUDED`. I could also fix this but since it's
been broken for so long and no one noticed, it's probably not necessary.
Reviewed By: emaste
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D14317
The current chain command does accept only device, allow also a file to be used,
such as /boot/pmbr or /boot/mbr (or stored third party MBR/VBR block).
Also fix file descriptor leak.
Rely on the kernel to appropriately mark group members as skipped.
Once a group is skipped we can clear the update flag on all the members.
PR: 229241
Submitted by: Andreas Longwitz <longwitz AT incore.de>
MFC after: 1 week
The original NVMe API used bit-fields to represent fields in data
structures defined by the specification (e.g. the op-code in the command
data structure). The implementation targeted x86_64 processors and
defined the bit fields for little endian dwords (i.e. 32 bits).
This approach does not work as-is for big endian architectures and was
changed to use a combination of bit shifts and masks to support PowerPC.
Unfortunately, this changed the NVMe API and forces #ifdef's based on
the OS revision level in user space code.
This change reverts to something that looks like the original API, but
it uses bytes instead of bit-fields inside the packed command structure.
As a bonus, this works as-is for both big and little endian CPU
architectures.
Bump __FreeBSD_version to 1200081 due to API change
Reviewed by: imp, kbowling, smh, mav
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D16404
This includes some light rework to simplify the line parsing, as well. If
we hit a line match, we'll always either use the line and move on to the
next line, or we'll spew out malformed line errors.
We had multiple spots to output the error and set the status based on
whether we had a non-nil first capture group or failed EOL validation, but
it was always the same error. Light rework entails a small label jump to
skip error handling and elimination of 'found' local.
As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.
Users on powerpc, 32-bit hardware, or with GPUs predating Radeon
and i915 will need to install the graphics/drm-legacy-kmod. All
other users should be able to use one of the LinuxKPI-based ports:
graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod.
MFC: never
Approved by: core@
A couple of issues addressed:
1.) Modules with - in the name were not recognized as modules
2.) The module regex was repeated for each place a module name may appear
3.) The 'strip leading space' bits were repeated for each expression
4.) The trailing 'comment validation' stuff was repeated every expression
#4 still has some more work to be done. exec lines, for instance, don't
capture a 'value' -- there's only one capture pattern. This throws off the
'c' value that we match, so the trailing bits aren't *actually* being
validated. This isn't a new issue, though, so a future comit will address
this.
Prevent some classes of foot-shooting that may result in permissions
problems.
Reviewed by: dab, delphij, vangyzen (earlier version)
Relnotes: yes (behavior change)
Sponsored by: Dell EMC Isilon
Differential Revision: D16831
muge(4) is the USB ethernet adapter that is used in RPi 3B+. Shipping it
in GENERIC kernel allows using NFS root out of the box instead of either
building custom kernel or modifying loader.conf for early loading of if_muge.ko
No objections: emaste
This helps with pkgbase by switching to CONFS so they are properly tagged as
config files.
Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16833
The requested size was returned incorrectly in case uio == NULL from listextattr because the
nameprefix/name conversion was not applied.
Also, make a_size/uio returning logic more unified with other filesystems.
Reviewed by: cem, pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13528
Michal Meloun reports that it breaks ctype (isspace()..) related
functions on armv7 so back out while we diagnose the issue.
Reported by: Michal Meloun <melounmichal@gmail.com>
In pre-SMPng, the global 'imen' was used to track mask state of the
hardware interrupts and was aligned to the masks used by spl*().
When the atpic code was converted to using the x86 interrupt source
abstraction, the global 'imen' was preserved by having each PIC
instance point to an invididual byte in the global 'imen' to hold its
8-bit interrupt mask. The global 'imen' is no longer used for
anything however, so rather than storing pointers in 'struct atpic',
just store the individual 8-bit mask for each PIC as a char.
While here, convert the ATPIC macro to using C99 initializers.
Reviewed by: kib, imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16827
