Link with --no-undefined-version by default. Will detect and prevent
the accidental removal of symbols from versioned libraries.
(cherry picked from commit 4510f2ca91)
This reverts commit b25ceb97ed.
Reviewed by: arichardson, kib, dim, emaste
Differential Revision: https://reviews.freebsd.org/D44216
Loading modules via kld_list is no longer substantially faster than via
loader.conf.
[skip ci]
MFC after: 2 weeks
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D45242
gcc doesn't have -m32 support on aarch64 so mark LIB32 broken there.
We have to check both COMPILER_TYPE and X_COMPILER_TYPE becuase
X_COMPILER_TYPE is only conditionally set and COMPILER_TYPE is the host
compiler in Makefile.inc1.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45089
Filesystem manual pages describe drivers, not formats;
except for fs, which describes the structures of ffs/ufs,
not how to use it in the system.
Reported by: emaste
Reviewed by: des, imp, meena (previous version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1077
In the future, we will Default to _FORTIFY_SOURCE=2 if SSP is enabled,
otherwise default to _FORTIFY_SOURCE=0. For now we default it to 0
unconditionally to ease bisect across older versions without the new
symbols, and we'll put out a call for testing.
include/*.h include their ssp/*.h equivalents as needed based on the
knob. Programs and users are allowed to override FORTIFY_SOURCE in their
Makefiles or src.conf/make.conf to force it off.
Reviewed by: des, markj
Relnotes: yes
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D32308
<sysexits.h> was deprecated in the base system in a1432b4 for FreeBSD
8.0 and is retained only for backwards compatibility. Make that clear,
since sysexits(3) suggested using it since it was in style(9) prior
to this.
MFC after: 1 week
Co-authored-by: imp
Fixes: a1432b4
Reviewed by: imp, pauamma (previous version)
Pull Request https://github.com/freebsd/freebsd-src/pull/1195
When this driver was written it made sense to make this default to off,
but these days almost all BIOSses will do the right thing. Furthermore
non-mmio communication only works on Intel architectures.
So lets default to allowing mmio, but not change the semantics of the
AHC_ALLOW_MEMIO flag to not break existing installs. Also document the
already existing hint.ahc.<unit>.allow_memio.
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp (small style tweak)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1219
Add a sound(4) bridge device driver for the RME HDSP 9632 and HDSP 9652
sound cards. These cards require a nowadays rare PCI 32bit (not PCIe)
slot, but still see use due to their value and wealth of features.
The HDSP 9632 is mostly comparable to the newer HDSPe AIO, while the
HDSP 9652 is similar to the HDSPe RayDAT. These HDSPe PCIe cards are
supported by the snd_hdspe(4) driver which was taken as a starting point
for development of snd_hdsp(4).
Implementation is kept separately due to substantial differences in
hardware configuration and to allow easy removal in case PCI 32bit
support would be phased out in the future.
The snd_hdsp(4) kernel module is not enabled by default, and can be
loaded at runtime with kldload(8) or during boot via loader.conf(5).
Basic operation was tested with both cards, not including all optional
cable connectors and expansion boards. Features should be roughly on par
with the snd_hdspe(4) supported cards.
Reviewed by: christos, br
Differential Revision: https://reviews.freebsd.org/D45112
This dates way, way back with the original net80211 support w/ atheros chips.
The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.
I changed this back in 2012 to disable supporting hardware WEP for AR5210
so if_ath(4) / net80211 crypto is all done in software and yes,
I could do CCMP/TKIP on AR5210 in software.
Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
encryption / decryption path.
But then if you enable the raw transmit/receive frame format it ALSO
bypasses the hardware encryption/decryption engine!
So for those NICs:
* If you want to do encryption, you can only use the firmware supported
ciphers w/ wifi direct or ethernet;
* If you want to use software encrypt/decrypt, you MUST disable all encryption
and instead use 100% software encryption.
The wpa_supplicant bsd driver code has a specific comment about this and
flips on supporting WEP/TKIP/CCMP, which is understandable but it doesn't
fix the ACTUAL intention of all of this stuff.
So:
* create a new field, ic_sw_cryptocaps
* populate it with the default supported set of ciphers for net80211
(right now wep, tkip, ccmp)
* Communicate the combination of both ic_sw_cryptocaps and ic_cryptocaps
to wpa_supplicant via the relevant devcap ioctl.
* Update manpage.
I'll follow this up with a driver_bsd.c change in wpa_supplicant to
trust this again, and then start adding the other cipher support there.
Differential Revision: https://reviews.freebsd.org/D44820
Microchip Technology acquired SMSC in 2012, and all current products
and datasheets refer to the devices supported by this driver as
Microchip parts. Mention SMSC in a parenthetical comment to explain
the driver's name.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45115
Add minimal sg(4) manual page. This implements a subset of the Linux
IOCTL interface for either native FreeBSD programs, or for Linux
binaries in the linuxulator.
Noticed by: Lexi Winter
Sponsored by: Netflix
It's not 1996 anymore, and we use CIDR nowadays. Update the various
ifconfig_ examples to use CIDR notation instead of netmasks, and also
add an example of a basic ifconfig_ entry that most users will be
interested in.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1217
Previously it was only possible to enable target mode for these drivers
by rebuilding the kernel with AHC_TMODE_ENABLE or AHD_TMODE_ENABLE and a
bitmask of which units to statically enable for target mode.
There is no space-savings in the driver by not having AHC_TMODE_ENABLE
set, so in addition to the compile time option lets also introduce some
tunables:
hint.ahc.<unit>.tmode_enable=0/1
hint.ahd.<unit>.tmode_enable=0/1
For compatibility the old behavior is retained, but it can be overridden
with tunables
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/1208
This is the server (target in SCSI terms) for NVMe over Fabrics.
Userland is responsible for accepting a new queue pair and receiving
the initial Connect command before handing the queue pair off via an
ioctl to this CTL frontend.
This frontend exposes CTL LUNs as NVMe namespaces to remote hosts.
Users can ask LUNS to CTL that can be shared via either iSCSI or
NVMeoF.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44726
This is the client (initiator in SCSI terms) for NVMe over Fabrics.
Userland is responsible for creating a set of queue pairs and then
handing them off via an ioctl to this driver, e.g. via the 'connect'
command from nvmecontrol(8). An nvmeX new-bus device is created
at the top-level to represent the remote controller similar to PCI
nvmeX devices for PCI-express controllers.
As with nvme(4), namespace devices named /dev/nvmeXnsY are created and
pass through commands can be submitted to either the namespace devices
or the controller device. For example, 'nvmecontrol identify nvmeX'
works for a remote Fabrics controller the same as for a PCI-express
controller.
nvmf exports remote namespaces via nda(4) devices using the new NVMF
CAM transport. nvmf does not support nvd(4), only nda(4).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44714
Structurally this is very similar to the TCP transport for iSCSI
(icl_soft.c). One key difference is that NVMeoF transports use a more
abstract interface working with NVMe commands rather than transport
PDUs. Thus, the data transfer for a given command is managed entirely
in the transport backend.
Similar to icl_soft.c, separate kthreads are used to handle transmit
and receive for each queue pair. On the transmit side, when a capsule
is transmitted by an upper layer, it is placed on a queue for
processing by the transmit thread. The transmit thread converts
command response capsules into suitable TCP PDUs where each PDU is
described by an mbuf chain that is then queued to the backing socket's
send buffer. Command capsules can embed data along with the NVMe
command.
On the receive side, a socket upcall notifies the receive kthread when
more data arrives. Once enough data has arrived for a PDU, the PDU is
handled synchronously in the kthread. PDUs such as R2T or data
related PDUs are handled internally, with callbacks invoked if a data
transfer encounters an error, or once the data transfer has completed.
Received capsule PDUs invoke the upper layer's capsule_received
callback.
struct nvmf_tcp_command_buffer manages a TCP command buffer for data
transfers that do not use in-capsule-data as described in the NVMeoF
spec. Data related PDUs such as R2T, C2H, and H2C are associated with
a command buffer except in the case of the send_controller_data
transport method which simply constructs one or more C2H PDUs from the
caller's mbuf chain.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44712
libnvmf provides APIs for transmitting and receiving Command and
Response capsules along with data associated with NVMe commands.
Capsules are represented by 'struct nvmf_capsule' objects.
Capsules are transmitted and received on queue pairs represented by
'struct nvmf_qpair' objects.
Queue pairs belong to an association represented by a 'struct
nvmf_association' object.
libnvmf provides additional helper APIs to assist with constructing
command capsules for a host, response capsules for a controller,
connecting queue pairs to a remote controller and optionally
offloading connected queues to an in-kernel host, accepting queue pair
connections from remote hosts and optionally offloading connected
queues to an in-kernel controller, constructing controller data
structures for local controllers, etc.
libnvmf also includes an internal transport abstraction as well as an
implementation of a userspace TCP transport.
libnvmf is primarily intended for ease of use and low-traffic use cases
such as establishing connections that are handed off to the kernel.
As such, it uses a simple API built on blocking I/O.
For a host, a consumer first populates an 'struct
nvmf_association_params' with a set of parameters shared by all queue
pairs for a single association such as whether or not to use SQ flow
control and header and data digests and creates a 'struct
nvmf_association' object. The consumer is responsible for
establishing a TCP socket for each queue pair. This socket is
included in the 'struct nvmf_qpair_params' passed to 'nvmf_connect' to
complete transport-specific negotiation, send a Fabrics Connect
command, and wait for the Connect reply. Upon success, a new 'struct
nvmf_qpair' object is returned. This queue pair can then be used to
send and receive capsules. A command capsule is allocated, populated
with an SQE and optional data buffer, and transmitted via
nvmf_host_transmit_command. The consumer can then wait for a reply
via nvmf_host_wait_for_response. The library also provides some
wrapper functions such as nvmf_read_property and nvmf_write_property
which send a command and wait for a response synchronously.
For a controller, a consumer uses a single association for a set of
incoming connections. A consumer can choose to use multiple
associations (e.g. a separate association for connections to a
discovery controller listening on a different port than I/O
controllers). The consumer is responsible for accepting TCP sockets
directly, but once a socket has been accepted it is passed to
nvmf_accept to perform transport-specific negotiation and wait for the
Connect command. Similar to nvmf_connect, nvmf_accept returns a newly
construct nvmf_qpair. However, in contrast to nvmf_connect,
nvmf_accept does not complete the Fabrics negotiation. The consumer
must explicitly send a response capsule before waiting for additional
command capsules to arrive. In particular, in the kernel offload
case, the Connect command and data are provided to the kernel
controller and the Connect response capsule is sent by the kernel once
it is ready to handle the new queue pair.
For userspace controller command handling, the consumer uses
nvmf_controller_receive_capsule to wait for a command capsule.
nvmf_receive_controller_data is used to retrieve any data from a
command (e.g. the data for a WRITE command). It can be called
multiple times to split the data transfer into smaller sizes.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. It also sends a response capsule indicating
success, or an error if an internal error occurs. nvmf_send_response
is used to send a response without associated data. There are also
several convenience wrappers such as nvmf_send_success and
nvmf_send_generic_error.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44710
Link with --no-undefined-version by default. Will detect and prevent
the accidental removal of symbols from versioned libraries.
Reviewed by: arichardson, kib, dim, emaste
Differential Revision: https://reviews.freebsd.org/D44216
Mergemaster has been deprecated for some time, and will be retired.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41799
For now, we enumerate disk devices before network devices. This is to
work around a problem wherein u-boot remaps BARs during boot in a way
that bhyve does not handle. Some discussion and experiments suggest
that this can be handled by having bhyve not map BARs during boot on
arm64; until a solution is implemented, however, this workaround is
sufficient for simple usage and doesn't have any real downsides.
The console and bootrom are specified slightly differently versus amd64,
and a few of vmrun.sh's command-line options are amd64-only.
Reviewed by: corvink, jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44933
Use a more specific description for this man page, and add SDPX tag
while here.
Reviewed by: imp, meena
Signed-off-by: Alexander Ziaee <concussious@runbox.com>
Pull Request: https://github.com/freebsd/freebsd-src/pull/1194
- A file descriptor obtained from accept(2), accept4(2) and openat(2)
is not always assigned all capability rights. Instead, it inherits
capability rights from the "parent" socket/dir file descriptor.
- getdents(2) and getdirentries(2) requires CAP_READ.
- openat(2) with O_WRONLY|O_TRUNC does not require CAP_SEEK.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1207
Macros to ANDNOT a bitset currently exist, but there are no ORNOT
equivalents. Introduce ORNOT macros for bitset(9), cpuset(9), and
domainset(9).
Approved by: markj (mentor)
Reviewed by: markj
MFC after: 1 week
Sponsored by: NIKSUN, Inc.
Differential Revision: https://reviews.freebsd.org/D44976
This commit broke "make makeman" checks in github CI due to a lack of
option description files. The split between VIMAGE and VIMAGE_SUPPORT
is not clearly justified and the code is broken because there is no
opt_vimage.h (it's in opt_global.h).
This reverts commit 22ca6db50f.
The drivers and utilities are now built and installed unconditionally.
Reviewed by: imp, emaste
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44843
xlocale.3: Comment out reference to atof_l(3), atoi_l(3), atol_l(3), atoll_l(3)
These manual page references do not exist.
lagg.4: Change the reference for /etc/rc.conf from a reference link
.Xr -> .Pa based on the context within the manual page it is used.
buf.9: Remove .Xr entries from the file
The buf.9 manual page contains a commented out .Xr reference.
The <filmmein> 9 entry is a placeholder and has been removed for
clarity.
Reviewed by: mhorne
Pull Request: https://github.com/freebsd/freebsd-src/pull/1114
Capsicum is non-optional as of c24c117b96 ("Remove
WITHOUT_{CAPSICUM,CASPER} options").
`#ifndef WITHOUT_CAPSICUM` is left in the source for the benefit of
downstream consumers, but is never defined in FreeBSD.
Reviewed by: oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42077
Several users with alc(4)-based "Killer" Ethernet cards have reported
issues with this driver not passing traffic, which are solved by
disabling MSI-X using the provided tunable.
To work around this issue, disable MSI-X by default on this card.
This is done by having msix_disable default to 2, which means
"auto-detect". The user can still override this to either 0 or 1 as
desired.
Since these are slow (1Gbps) Ethernet ICs used in low-end systems, it's
unlikely this will cause any practical performance issues; on the other
hand, the card not working by default likely causes issues for many new
FreeBSD users who find their network port doesn't work and have no idea
why.
PR: 230807
MFC after: 1 week
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1185
Allow a new variable SE_xxxPACKAGE to be used to place an example group
into a package.
Move the following examples into existing appropriate packages:
- bhyve examples into FreeBSD-bhyve
- bootforth examples into FreeBSD-bootloader
- csh examples into FreeBSD-csh
- ipfw examples into FreeBSD-ipfw
- jail examples into FreeBSD-jail
- pf examples into FreeBSD-pf
- ppp examples into FreeBSD-ppp
- printing examples into FreeBSD-lp
- uefisign examples into FreeBSD-efi-tools
- ypldap examples into FreeBSD-yp
- hast examples into FreeBSD-hast
Move all other examples into the new 'FreeBSD-examples' package.
This removes a significant number of files from the FreeBSD-utilities
package.
Reviewed by: imp, manu
Pull Request: https://github.com/freebsd/freebsd-src/pull/1176
- Remove superfluous whitespace by removing trailing whitespace
before `\` (line continuation character)
- Quote `SUBDIR.` to clarify the fact that this is a variable
reference--not the end of a sentence.
When in netmap (emulated) mode, wireguard interfaces prepend or strip a
dummy ethernet header when interfacing with netmap. The netmap
application thus sees unencrypted, de-encapsulated frames with a fixed
header.
In this mode, netmap hooks the if_input and if_transmit routines of the
ifnet. Packets from the host TX ring are handled by wg_if_input(),
which simply hands them to the netisr layer; packets which would
otherwise be tunneled are intercepted in wg_output() and placed in the
host RX ring.
The "physical" TX ring is processed by wg_transmit(), which behaves
identically to wg_output() when netmap is not enabled, and packets
appear in the "physical" RX ring by hooking wg_deliver_in().
Reviewed by: vmaffione
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Zenarmor
Differential Revision: https://reviews.freebsd.org/D43460
As discussed in bug 278417, some ports require the F16C instruction set
to compile, but there is no way yet to detect whether the currently
chosen CPUTYPE supports this feature.
Add the feature to the MACHINE_CPU variable, for each processor that
supports it. The list of processors was extracted from clang 18's -dM
output, filtered on the __F16C__ define.
PR: 278417
Reviewed by: brooks, emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D44848
Now that the handbook has been moved to ports, I think it's very nice to
have a network quickstart guide in-band, in base, in the system manual.
If the user uses any of the following terms "man -k
{network,networking,wifi,quickstart}" this page will come up, which is I
think a very common use case for new users.
Currently, this document explains connecting to a basic Ethernet
network, a basic wifi network, scanning for wifi networks, and airplane
mode, as well as linking to other sections, including the handbook
Co-authored-by: Graham Perrin <grahamperrin@gmail.com>
Reviewed by: imp, bcr, freebsd@igalic.co
Pull Request: https://github.com/freebsd/freebsd-src/pull/833
Following the convention used in the rest of this file, ${LIBPFCTLDIR}
should refer to the directory, and ${LIBPFCTL} to the library itself.
Instead, both values were assigned to ${LIBPFCTL}, and ${LIBPFCTLDIR} was
not set at all.
This appears to be a simple typo and not a deliberate choice, so fix it
by assigning the directory name to ${LIBPFCTLDIR} instead.
Modernize intro.1, attempting to preserve style and brevity,
including a paragraph about installing more commands, a FILES
section explaining where the commands are located and why, and
adding section number to HISTORY for clarity.
Advances: #248562
Reviewed by: imp, mhrone
Pull Request: https://github.com/freebsd/freebsd-src/pull/1136
Hot-unplugging a sound device, such as a USB sound card, whilst being
consumed by an application, results in an infinite loop until either the
application closes the device's file descriptor, or the channel
automatically times out after hw.snd.timeout seconds. In the case of a
detach however, the timeout approach is still not ideal, since we want
all resources to be released immediatelly, without waiting for N seconds
until we can use the bus again.
The timeout mechanism works by calling chn_sleep() in chn_read() and
chn_write() (see pcm/channel.c) in order to send the thread to sleep,
using cv_timedwait_sig(). Since chn_sleep() sets the CHN_F_SLEEPING flag
while waiting for cv_timedwait_sig() to return, we can test this flag in
pcm_unregister() (called during detach) and wakeup the sleeping
thread(s) to immediately kill the channel(s) being consumed.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
PR: 194727
Reviewed by: dev_submerge.ch, bapt, markj
Differential Revision: https://reviews.freebsd.org/D43545
Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
routing audio to the appropriate channel(s). This patch gets rid of the
whole snd_clone framework (including any related sysctls) and instead
uses DEVFS_CDEVPRIV(9) to handle device opening, channel allocation and
audio routing. This results in a significant reduction in code size as
well as complexity.
Behavior that is preserved:
- hw.snd.basename_clone.
- Exclusive access of an audio device (i.e VCHANs disabled).
- Multiple processes can read from/write to the device.
- A device can only be opened as many times as the maximum allowed
channel number (see SND_MAXHWCHAN in pcm/sound.h).
- OSSv4 compatibility aliases are preserved.
Behavior changes:
Only one /dev/dspX device node is created (on attach) for each audio
device, as opposed to the current /dev/dspX.Y devices created by
snd_clone. According to the sound(4) man page, devices are not meant to
be opened through /dev/dspX.Y anyway, so it is best if we do not create
device nodes for them in the first place. As a result of this, modify
dsp_oss_audioinfo() to print /dev/dspX in the "ai->devnode", instead of
/dev/dspX.Y.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: dev_submerge.ch, bapt, markj
Differential Revision: https://reviews.freebsd.org/D44411
The NVMe drivers are portable and are already included statically in
GENERIC on other architectures such as aarch64 and riscv64.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44690
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
Default to VIMAGE as yes.
Add VIMAGE to __DEFAULT_DEPENDENT_OPTIONS (to define VIMAGE_SUPPORT)
Only output VIMAGE to opt_global.h when VIMAGE support is wanted.
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39636
This will allow a userland machinery that orchestrates a bridge (e.g. a
jail or vm manager) to not double the number allocation logic. See bug
278130 for longer description and examples.
Reviewed by: glebius, afedorov
Differential Revision: https://reviews.freebsd.org/D44615
PR: 278130
This reverts commit 9eff58c6d5.
We are reverting dc831e93ba ("sound: Get rid of snd_clone and use
DEVFS_CDEVPRIV(9)"), so revert this commit as well since it depends
dc831e93ba.
Catch up with 10a1e981d (2019-03-19) so that one can do
'man SYSCTL_ADD_CONST_STRING' and not get
"No manual entry for SYSCTL_ADD_CONST_STRING".
Reviewed by: sjg
Hot-unplugging a sound device, such as a USB sound card, whilst being
consumed by an application, results in an infinite loop until either the
application closes the device's file descriptor, or the channel
automatically times out after hw.snd.timeout seconds. In the case of a
detach however, the timeout approach is still not ideal, since we want
all resources to be released immediatelly, without waiting for N seconds
until we can use the bus again.
The timeout mechanism works by calling chn_sleep() in chn_read() and
chn_write() (see pcm/channel.c) in order to send the thread to sleep,
using cv_timedwait_sig(). Since chn_sleep() sets the CHN_F_SLEEPING flag
while waiting for cv_timedwait_sig() to return, we can test this flag in
pcm_unregister() (called during detach) and wakeup the sleeping
thread(s) to immediately kill the channel(s) being consumed.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
PR: 194727, 278055, 202275, 220949, 272286
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D43545
Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
routing audio to the appropriate channel(s). This patch gets rid of the
whole snd_clone framework (including any related sysctls) and instead
uses DEVFS_CDEVPRIV(9) to handle device opening, channel allocation and
audio routing. This results in a significant reduction in code size as
well as complexity.
Behavior that is preserved:
- hw.snd.basename_clone.
- Exclusive access of an audio device (i.e VCHANs disabled).
- Multiple processes can read from/write to the device.
- A device can only be opened as many times as the maximum allowed
channel number (see SND_MAXHWCHAN in pcm/sound.h).
- OSSv4 compatibility aliases are preserved.
Behavior changes:
Only one /dev/dspX device node is created (on attach) for each audio
device, as opposed to the current /dev/dspX.Y devices created by
snd_clone. According to the sound(4) man page, devices are not meant to
be opened through /dev/dspX.Y anyway, so it is best if we do not create
device nodes for them in the first place. As a result of this, modify
dsp_oss_audioinfo() to print /dev/dspX in the "ai->devnode", instead of
/dev/dspX.Y.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D44411
This allows for setting a different compiler for building hostprogs
when cross compiling.
Obtained from: Juniper Networks, Inc.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D44536
This adds support for two new diff algorithms, Myers diff and Patience
diff.
These algorithms perform a different form of search compared to the
classic Stone algorithm and support escapes when worst case scenarios
are encountered.
Add the -A flag to allow selection of the algorithm, but default to
using the new Myers diff implementation.
The libdiff implementation currently only supports a subset of input and
output options supported by diff. When these options are used, but the
algorithm is not selected, automatically fallback to the classic Stone
algorithm until support for these modes can be added.
Based on work originally done by thj@ with contributions from kevans@.
Sponsored by: Klara, Inc.
Reviewed by: thj
Differential Revision: https://reviews.freebsd.org/D44302
There has not been planned changes so far to the interface. Remove the
section as it may not be relevant anymore.
Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D44501
The history section (added in CSRG) claimed both first appeared in v6.
Looking at the manuals in the TUHS archive, /dev/mem was in v1
and /dev/kmem was introduced in v5.
Reviewed by: imp
Obtained from: OpenBSD
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D44486
