Revert "LINT: Add mac_do"

This reverts commit 91b7b225b2ce577381aae989c361b9b5b6dd1500.

LINT: Add mac_do

Sponsored by: The FreeBSD Foundation

conf/NOTES: Remove trailing whitespace

Sponsored by: The FreeBSD Foundation

dummymbuf: add to LINT

filemon: Document how to build into the kernel.

MFC after: 3 days
Reviewed by: olce, imp
Differential Revision: https://reviews.freebsd.org/D46184

conf: Remove kernel stack swapping support, part 12

Remove the NO_SWAPPING option. There is still some code in
vm_swapout.c, but it relates to RACCT handling. Remove the option and
make compilatio

conf: Remove kernel stack swapping support, part 12

Remove the NO_SWAPPING option. There is still some code in
vm_swapout.c, but it relates to RACCT handling. Remove the option and
make compilation of vm_swapout.c conditional on RACCT.

Tested by: pho
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D46130

show more ...

NOTES: Correct swapped descriptions of virtio_scmi and virtio_scsi

Sponsored by: Chelsio Communications

bde: remove lingering references

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D45874

snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver.

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 PC

snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver.

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

show more ...

sockets: hide socket hhook(9)s under SOCKET_HHOOK

There are no in-tree consumers of these hooks.

Reviewed by: stevek
Differential Revision: https://reviews.freebsd.org/D44928

nvmft: The in-kernel NVMe over Fabrics controller

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 Co

nvmft: The in-kernel NVMe over Fabrics controller

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

show more ...

nvmf: The in-kernel NVMe over Fabrics host

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

nvmf: The in-kernel NVMe over Fabrics host

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

show more ...

nvmf_tcp: Add a TCP transport for NVMe over Fabrics

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 i

nvmf_tcp: Add a TCP transport for NVMe over Fabrics

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

show more ...

accf_tls: accept filter that waits for TLS handshake header

NOTES: Remove a double word in comment

- s/of of/of/

MFC after: 3 days

sys: Retire the ISCSI_INITIATOR_DEBUG option

This was used by the old iSCSI initiator, not the current one.

Reported by: trasz

NOTES: Move ENABLE_ALART option to MI NOTES next to intpm device

This option is for this driver.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44786

NOTES: Move the VirtIO entries to the MI NOTES file

While here, add virtio_gpu

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D44782

NOTES: Move safe(4) to the MI NOTES file

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44780

NOTES: Move IEEE80211_DEBUG_REFCNT to the MI NOTES file

This option is not specific to amd64

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44779

NOTES: Move NVMe entries to MI file

While here, adjust the sample setting for NVME_USE_NVD to use a
non-default setting as is typical in entries in NOTES.

Discussed with: imp
Reviewed by: manu
Spon

NOTES: Move NVMe entries to MI file

While here, adjust the sample setting for NVME_USE_NVD to use a
non-default setting as is typical in entries in NOTES.

Discussed with: imp
Reviewed by: manu
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44691

show more ...

NOTES: Tidy entries for SATA controllers

- Add typical comments after device entries (copied from amd64
GENERIC)

- Add an entry for 'device ada'. Normally this is pulled in via
'device sd', bu

NOTES: Tidy entries for SATA controllers

- Add typical comments after device entries (copied from amd64
GENERIC)

- Add an entry for 'device ada'. Normally this is pulled in via
'device sd', but is documented in ada(4) and can be used to include
ATA/SATA disk support in a kernel without SCSI disk support.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44689

show more ...

NOTES: Add devices for iSCSI support

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44688

NOTES: Move OFED options to MI NOTES

Disable in armv7 NOTES to match sys/modules/Makefile

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D4

NOTES: Move OFED options to MI NOTES

Disable in armv7 NOTES to match sys/modules/Makefile

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44686

show more ...

Add the BBR and RACK stacks to the LINT kernel.

While here, drop the EXTRA_TCP_STACKS option, which serves no purpose and
should never have been added. Instead, build bbr and rack as long as
either

Add the BBR and RACK stacks to the LINT kernel.

While here, drop the EXTRA_TCP_STACKS option, which serves no purpose and
should never have been added. Instead, build bbr and rack as long as
either or both of INET and INET6 is enabled. There is no risk to anyone
who doesn't load one or both and then twiddle the relevant sysctls.

Differential Revision: https://reviews.freebsd.org/D42088

show more ...