src/sys/modules/Makefile, branch releng/12.2

ice(4): Add Intel 100GbE Ethernet Driver to kernel

2020-09-14T22:42:17Z

This also adds the "package" file that's loaded by the device for configuration, used in the included ice_ddp kernel module. MFS of r365612 and r365731. Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation

MFC r364973:

2020-09-06T10:18:59Z

Driver for 4x10Gb Ethernet reference NIC FPGA design for NetFPGA SUME development board. Submitted by: Denis Salopek Reviewed by: zec, bz (src); rgrimes, bcr (manpages) Sponsored by: Google Summer of Code 2020 Differential Revision: https://reviews.freebsd.org/D26074

MFC r360035-r360037: Split XDR off, minimize ZFS dependency

2020-09-05T02:16:10Z

__FreeBSD_version bumped to indicate the change. r360035: Move M_RPC malloc type into XDR. Both RPC and XDR libraries use this type, but since RPC depends on XDR (not vice versa) we need it defined in XDR to make the module loadable without RPC. r360036: Split XDR into separate kernel module. Make krpc depend on xdr. r360037: Make ZFS depend on xdr.ko only. It doesn't need kernel RPC.

MFC 361638,361712: Only build ipsec modules for kernels with IPSEC_SUPPORT.

2020-09-02T21:36:55Z

361638: Only build ipsec modules if the kernel includes IPSEC_SUPPORT. Honoring the kernel-supplied opt_ipsec.h in r361632 causes builds of ipsec modules to fail if the kernel doesn't include IPSEC_SUPPORT. However, the module can never be loaded into such a kernel, so only build the modules if the kernel includes IPSEC_SUPPORT. 361712: (kevans) modules: don't build ipsec/tcpmd5 if the kernel is configured for IPSEC IPSEC_SUPPORT can currently only cope with either IPSEC || IPSEC_SUPPORT, not both. Refrain from building if IPSEC is set, as the resulting module won't be able to load anyways if it's built into the kernel. KERN_OPTS is safe here; for tied modules, it will reflect the kernel configuration. For untied modules, it will defer to whatever is set in ^/sys/conf/config.mk, which doesn't set IPSEC for modules. The latter situation has some risk to it for uncommon scenarios, but such is the life of untied kernel modules.

MFC r358908: Enable ixl device on PowerPC64

2020-07-30T19:11:01Z

Relnotes: yes

Update the expression used to decide whether to build sctp.ko.

2020-07-27T15:09:07Z

This is a direct commit to stable/12. Reported by: Jenkins

MFC r363079, r363080, r363129, r363133:

2020-07-27T14:41:23Z

Provide support for building SCTP as a loadable module.

MFC r363180, r363182, r363251:

2020-07-22T14:22:35Z

Add a driver for the SafeXcel EIP-97.

MFC r349580,r351740,r353432,r353433,r354079,r354080: add superio driver

2019-11-04T09:49:58Z

The goal of this driver is consolidate information about SuperIO chips and to provide for peaceful coexistence of drivers that need to access SuperIO configuration registers. While SuperIO chips can host various functions most of them are discoverable and accessible without any knowledge of the SuperIO. Examples are: keyboard and mouse controllers, UARTs, floppy disk controllers. SuperIO-s also provide non-standard functions such as GPIO, watchdog timers and hardware monitoring. Such functions do require drivers with a knowledge of a specific SuperIO. At this time the driver supports a number of ITE and Nuvoton (fka Winbond) SuperIO chips. There is a single driver for all devices. So, I have not done the usual split between the hardware driver and the bus functionality. Although, superio does act as a bus for devices that represent known non-standard functions of a SuperIO chip. The bus provides enumeration of child devices based on the hardcoded knowledge of such functions. The knowledge as extracted from datasheets and other drivers. As there is a single driver, I have not defined a kobj interface for it. So, its interface is currently made of simple functions. I think that we can the flexibility (and complications) when we actually need it.

MFC tun/tap merge: r347241, r347394, r347404, r347483, r351220, r351229,

2019-10-25T01:10:08Z

r352148, r353056-r353057, r353781-r353782, r353785-r353786, r353877 Note: A little more than just the tun/tap merge has been MFC'd to ease auditing correctness/differences, as some later commits were cherry-picked back to tun+tap. r347241: tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. r347394: tuntap: Properly detach tap ifp r347404: tuntap: Don't down tap interfaces if LINK0 is set r347483: tuntap: Improve style No functional change. tun_flags of the tuntap_driver was renamed to ident_flags to reflect the fact that it's a subset of the tun_flags that identifies a tuntap device. This maps more easily (visually) to the TUN_DRIVER_IDENT_MASK that masks off the bits of tun_flags that are applicable to tuntap driver ident. This is a purely cosmetic change. r351220: if_tuntap: minor improvements Rewrite a loop to avoid duplicating the exit condition. Simplify mask processing in tunpoll(). Fix minor typos. r351229: tuntap: belatedly add MODULE_VERSION for if_tun and if_tap When tun/tap were merged, appropriate MODULE_VERSION should have been added for things like modfind(2) to continue to do the right thing with the old names. r352148: Remove empty tap/tun modules directories after r347241 r353056: if_tuntap: add a busy/unbusy mechanism, replace destroy OPEN check A future commit will create device aliases when a tuntap device is renamed so that it's still easily found in /dev after the rename. Said mechanism will want to keep the tun alive long enough to either realize that it's about to go away or complete the alias creation, even if the alias is about to get destroyed. While we're introducing it, using it to prevent open devices from going away makes plenty of sense and keeps the logic on waking up tun_destroy clean, so we don't have multiple places trying to cv_broadcast unless it's still in use elsewhere. r353057: if_tuntap: create /dev aliases when a tuntap device gets renamed Currently, if you do: $ ifconfig tun0 create $ ifconfig tun0 name wg0 $ ls -l /dev | egrep 'wg|tun' You will see tun0, but no wg0. In fact, it's slightly more annoying to make the association between the new name and the old name in order to open the device (if it hadn't been opened during the rename). Register an eventhandler for ifnet_arrival_events and catch interface renames. We can determine if the ifnet is a tun easily enough from the if_dname, which matches the cevsw.d_name from the associated tuntap_driver. Some locking dance is required because renames don't require the device to be opened, so it could go away in the middle of handling the ioctl, but as soon as we've verified this isn't the case we can attempt to busy the tun and either bail out if the tun device is dying, or we can proceed with the rename. We only create these aliases on a best-effort basis. Renaming a tun device to "usbctl", which doesn't exist as an ifnet but does as a /dev, is clearly not that disastrous, but we can't and won't create a /dev for that. r353781: tuntap(4): Drop TUN_IASET This flag appears to have been effectively unused since introduction to if_tun(4) -- drop it now. r353782: tuntap(4): break out after setting TUN_DSTADDR This is now the only flag we set in this loop, terminate early. r353785: tuntap(4): Use make_dev_s to avoid si_drv1 race This allows us to avoid some dance in tunopen for dealing with the possibility of dev->si_drv1 being NULL as it's set prior to the devfs node being created in all cases. There's still the possibility that the tun device hasn't been fully initialized, since that's done after the devfs node was created. Alleviate this by returning ENXIO if we're not to that point of tuncreate yet. This work is what sparked r353128, full initialization of cloned devices w/ specified make_dev_args. r353786: tuntap(4): use cdevpriv w/ dtor for last close instead of d_close cdevpriv dtors will be called when the reference count on the associated struct file drops to 0, while d_close can be unreliable for cleaning up state at "last close" for a number of reasons. As far as tunclose/tundtor is concerned the difference is minimal, so make the switch. r353877: tuntap(4): properly declare if_tun and if_tap modules Simply adding MODULE_VERSION does not do the trick, because the modules haven't been declared. This should actually fix modfind/kldstat, which r351229 aimed and failed to do. This should make vm-bhyve do the right thing again when using the ports version, rather than the latest version not in ports. Relnotes: yes