1999-08-28 01:08:13 +00:00
|
|
|
# $FreeBSD$
|
1994-09-16 20:24:29 +00:00
|
|
|
|
2017-03-04 10:10:17 +00:00
|
|
|
SYSDIR?=${SRCTOP}/sys
|
2014-08-11 14:50:49 +00:00
|
|
|
.include "${SYSDIR}/conf/kern.opts.mk"
|
2006-03-17 18:54:44 +00:00
|
|
|
|
2014-05-12 13:33:12 +00:00
|
|
|
SUBDIR_PARALLEL=
|
|
|
|
|
|
2012-02-04 00:54:43 +00:00
|
|
|
# Modules that include binary-only blobs of microcode should be selectable by
|
|
|
|
|
# MK_SOURCELESS_UCODE option (see below).
|
|
|
|
|
|
2020-02-16 15:43:28 +00:00
|
|
|
.include "${SYSDIR}/conf/config.mk"
|
|
|
|
|
|
2014-08-11 17:04:04 +00:00
|
|
|
.if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES)
|
|
|
|
|
SUBDIR=${MODULES_OVERRIDE}
|
|
|
|
|
.else
|
2012-06-05 17:44:54 +00:00
|
|
|
SUBDIR= \
|
|
|
|
|
${_3dfx} \
|
2006-03-03 21:37:38 +00:00
|
|
|
${_3dfx_linux} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_aac} \
|
2013-05-24 09:22:43 +00:00
|
|
|
${_aacraid} \
|
2004-01-16 15:55:29 +00:00
|
|
|
accf_data \
|
2008-07-18 14:44:51 +00:00
|
|
|
accf_dns \
|
2001-07-15 04:55:37 +00:00
|
|
|
accf_http \
|
2012-03-13 20:28:42 +00:00
|
|
|
acl_nfs4 \
|
|
|
|
|
acl_posix1e \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_acpi} \
|
2008-10-03 10:31:31 +00:00
|
|
|
ae \
|
2010-07-23 11:00:46 +00:00
|
|
|
${_aesni} \
|
2008-05-19 01:53:47 +00:00
|
|
|
age \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_agp} \
|
Separate the parallel scsi knowledge out of the core of the XPT, and
modularize it so that new transports can be created.
Add a transport for SATA
Add a periph+protocol layer for ATA
Add a driver for AHCI-compliant hardware.
Add a maxio field to CAM so that drivers can advertise their max
I/O capability. Modify various drivers so that they are insulated
from the value of MAXPHYS.
The new ATA/SATA code supports AHCI-compliant hardware, and will override
the classic ATA driver if it is loaded as a module at boot time or compiled
into the kernel. The stack now support NCQ (tagged queueing) for increased
performance on modern SATA drives. It also supports port multipliers.
ATA drives are accessed via 'ada' device nodes. ATAPI drives are
accessed via 'cd' device nodes. They can all be enumerated and manipulated
via camcontrol, just like SCSI drives. SCSI commands are not translated to
their ATA equivalents; ATA native commands are used throughout the entire
stack, including camcontrol. See the camcontrol manpage for further
details. Testing this code may require that you update your fstab, and
possibly modify your BIOS to enable AHCI functionality, if available.
This code is very experimental at the moment. The userland ABI/API has
changed, so applications will need to be recompiled. It may change
further in the near future. The 'ada' device name may also change as
more infrastructure is completed in this project. The goal is to
eventually put all CAM busses and devices until newbus, allowing for
interesting topology and management options.
Few functional changes will be seen with existing SCSI/SAS/FC drivers,
though the userland ABI has still changed. In the future, transports
specific modules for SAS and FC may appear in order to better support
the topologies and capabilities of these technologies.
The modularization of CAM and the addition of the ATA/SATA modules is
meant to break CAM out of the mold of being specific to SCSI, letting it
grow to be a framework for arbitrary transports and protocols. It also
allows drivers to be written to support discrete hardware without
jeopardizing the stability of non-related hardware. While only an AHCI
driver is provided now, a Silicon Image driver is also in the works.
Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware
is possible and encouraged. Help with new transports is also encouraged.
Submitted by: scottl, mav
Approved by: re
2009-07-10 08:18:08 +00:00
|
|
|
ahci \
|
2002-11-03 23:48:14 +00:00
|
|
|
aic7xxx \
|
2009-06-10 02:07:58 +00:00
|
|
|
alc \
|
2008-11-12 09:52:06 +00:00
|
|
|
ale \
|
2010-03-31 03:58:57 +00:00
|
|
|
alq \
|
2017-03-03 22:51:04 +00:00
|
|
|
${_amd_ecc_inject} \
|
2018-10-21 04:52:37 +00:00
|
|
|
${_amdgpio} \
|
2009-11-30 11:44:03 +00:00
|
|
|
${_amdsbwd} \
|
2017-09-05 15:13:41 +00:00
|
|
|
${_amdsmn} \
|
2009-10-20 13:22:54 +00:00
|
|
|
${_amdtemp} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_aout} \
|
2005-03-31 20:21:43 +00:00
|
|
|
${_arcmsr} \
|
2018-05-17 10:19:52 +00:00
|
|
|
${_allwinner} \
|
2016-11-21 11:18:00 +00:00
|
|
|
${_armv8crypto} \
|
2007-11-07 20:08:15 +00:00
|
|
|
${_asmc} \
|
This is the much rumoured ATA mkIII update that I've been working on.
o ATA is now fully newbus'd and split into modules.
This means that on a modern system you just load "atapci and ata"
to get the base support, and then one or more of the device
subdrivers "atadisk atapicd atapifd atapist ataraid".
All can be loaded/unloaded anytime, but for obvious reasons you
dont want to unload atadisk when you have mounted filesystems.
o The device identify part of the probe has been rewritten to fix
the problems with odd devices the old had, and to try to remove
so of the long delays some HW could provoke. Also probing is done
without the need for interrupts, making earlier probing possible.
o SATA devices can be hot inserted/removed and devices will be created/
removed in /dev accordingly.
NOTE: only supported on controllers that has this feature:
Promise and Silicon Image for now.
On other controllers the usual atacontrol detach/attach dance is
still needed.
o Support for "atomic" composite ATA requests used for RAID.
o ATA RAID support has been rewritten and and now supports these
metadata formats:
"Adaptec HostRAID"
"Highpoint V2 RocketRAID"
"Highpoint V3 RocketRAID"
"Intel MatrixRAID"
"Integrated Technology Express"
"LSILogic V2 MegaRAID"
"LSILogic V3 MegaRAID"
"Promise FastTrak"
"Silicon Image Medley"
"FreeBSD PseudoRAID"
o Update the ioctl API to match new RAID levels etc.
o Update atacontrol to know about the new RAID levels etc
NOTE: you need to recompile atacontrol with the new sys/ata.h,
make world will take care of that.
NOTE2: that rebuild is done differently from the old system as
the rebuild is now done piggybacked on read requests to the
array, so atacontrol simply starts a background "dd" to rebuild
the array.
o The reinit code has been worked over to be much more robust.
o The timeout code has been overhauled for races.
o Support of new chipsets.
o Lots of fixes for bugs found while doing the modulerization and
reviewing the old code.
Missing or changed features from current ATA:
o atapi-cd no longer has support for ATAPI changers. Todays its
much cheaper and alot faster to copy those CD images to disk
and serve them from there. Besides they dont seem to be made
anymore, maybe for that exact reason.
o ATA RAID can only read metadata from all the above metadata formats,
not write all of them (Promise and Highpoint V2 so far). This means
that arrays can be picked up from the BIOS, but they cannot be
created from FreeBSD. There is more to it than just the missing
write metadata support, those formats are not unique to a given
controller like Promise and Highpoint formats, instead they exist
for several types, and even worse, some controllers can have
different formats and its impossible to tell which one.
The outcome is that we cannot reliably create the metadata of those
formats and be sure the controller BIOS will understand it.
However write support is needed to update/fail/rebuild the arrays
properly so it sits fairly high on the TODO list.
o So far atapicam is not supported with these changes. When/if this
will change is up to the maintainer of atapi-cam so go there for
questions.
HW donated by: Webveveriet AS
HW donated by: Frode Nordahl
HW donated by: Yahoo!
HW donated by: Sentex
Patience by: Vife and my boys (and even the cats)
2005-03-30 12:03:40 +00:00
|
|
|
ata \
|
2008-12-01 16:53:01 +00:00
|
|
|
ath \
|
[ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.
In the deep past, when this code compiled as a binary module, ath_hal
built as a module. This allowed custom, smaller HAL modules to be built.
This was especially beneficial for small embedded platforms where you
didn't require /everything/ just to run.
However, sometime around the HAL opening fanfare, the HAL landed here
as one big driver+HAL thing, and a lot of the (dirty) infrastructure
(ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away.
This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't
really floated up to the modules themselves.
I'm now in a position where for the reaaaaaly embedded boards (both the
really old and the last couple generation of QCA MIPS boards) having a
cut down HAL module and driver loaded at runtime is /actually/ beneficial.
This reduces the kernel size down by quite a bit. The MIPS modules look
like this:
adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko
-r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko
-r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko
-r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko
-r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko
-r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko
And the x86 versions, like this:
root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko
-r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko
-r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko
-r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko
-r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko
-r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko
-r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko
-r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko
-r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko
-r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko
.. so you can see, not building the whole HAL can save quite a bit.
For example, if you don't need AR9300 support, you can actually avoid
wasting half a megabyte of RAM. On embedded routers this is quite a
big deal.
The AR9300 HAL can be later further shrunk because, hilariously,
it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support.
(I'll chase that down later as it's quite a big savings if you're only
building for a single embedded target.)
So:
* Create a very hackish way to load/unload HAL modules
* Create module metadata for each HAL subtype - ah_osdep_arXXXX.c
* Create module metadata for ath_rate and ath_dfs (bluetooth is
currently just built as part of it)
* .. yes, this means we could actually build multiple rate control
modules and pick one at load time, but I'd rather just glue this
into net80211's rate control code. Oh well, baby steps.
* Main driver is now "ath_main"
* Create an "if_ath" module that does what the ye olde one did -
load PCI glue, main driver, HAL and all child modules.
In this way, if you have "if_ath_load=YES" in /boot/modules.conf
it will load everything the old way and stuff should still work.
* For module autoloading purposes, I actually /did/ fix up
the name of the modules in if_ath_pci and if_ath_ahb.
If you want to selectively load things (eg on ye cheape ARM/MIPS platforms
where RAM is at a premium) you should:
* load ath_hal
* load the chip modules in question
* load ath_rate, ath_dfs
* load ath_main
* load if_ath_pci and/or if_ath_ahb depending upon your particular
bus bind type - this is where probe/attach is done.
TODO:
* AR5312 module and associated pieces - yes, we have the SoC side support
now so the wifi support would be good to "round things out";
* Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet
structures; this'll simplify other things.
* Should add a simple refcnt thing to the HAL RF/chip modules so you
can't unload them whilst you're using them.
* Manpage updates, UPDATING if appropriate, etc.
2017-05-25 04:18:46 +00:00
|
|
|
ath_dfs \
|
|
|
|
|
ath_hal \
|
|
|
|
|
ath_hal_ar5210 \
|
|
|
|
|
ath_hal_ar5211 \
|
|
|
|
|
ath_hal_ar5212 \
|
|
|
|
|
ath_hal_ar5416 \
|
|
|
|
|
ath_hal_ar9300 \
|
|
|
|
|
ath_main \
|
|
|
|
|
ath_rate \
|
2011-03-31 08:07:13 +00:00
|
|
|
ath_pci \
|
2015-01-26 07:15:49 +00:00
|
|
|
${_autofs} \
|
2020-10-11 16:01:16 +00:00
|
|
|
axgbe \
|
2020-10-02 18:18:01 +00:00
|
|
|
backlight \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_bce} \
|
2018-01-22 07:10:30 +00:00
|
|
|
${_bcm283x_clkman} \
|
2018-01-21 21:27:41 +00:00
|
|
|
${_bcm283x_pwm} \
|
2003-09-09 18:17:23 +00:00
|
|
|
bfe \
|
2001-09-27 23:55:28 +00:00
|
|
|
bge \
|
[bwn] [bhnd] initial support for using bhnd for if_bwn devices.
This is an initial work in progress to use the replacement bhnd
bus code for devices which support it.
* Add manpage updates for bhnd, bhndb, siba
* Add kernel options for bhnd, bhndbus, etc
* Add initial support in if_bwn_pci / if_bwn_mac for using bhnd
as the bus transport for suppoted NICs
* if_bwn_pci will eventually be the PCI bus glue to interface to bwn,
which will use the right backend bus to attach to, versus direct
nexus/bhnd attachments (as found in embedded broadcom devices.)
The PCI glue defaults to probing at a lower level than the bwn glue,
so bwn should still attach as per normal without a boot time tunable set.
It's also not fully fleshed out - the bwn probe/attach code needs to be
broken out into platform and bus specific things (just like ath, ath_pci,
ath_ahb) before we can shift the driver over to using this.
Tested:
* BCM4311, STA mode
* BCM4312, STA mode
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6191
2016-05-04 23:38:27 +00:00
|
|
|
bhnd \
|
2011-04-25 21:53:41 +00:00
|
|
|
${_bxe} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_bios} \
|
Import Blake2 algorithms (blake2b, blake2s) from libb2
The upstream repository is on github BLAKE2/libb2. Files landed in
sys/contrib/libb2 are the unmodified upstream files, except for one
difference: secure_zero_memory's contents have been replaced with
explicit_bzero() only because the previous implementation broke powerpc
link. Preferential use of explicit_bzero() is in progress upstream, so
it is anticipated we will be able to drop this diff in the future.
sys/crypto/blake2 contains the source files needed to port libb2 to our
build system, a wrapped (limited) variant of the algorithm to match the API
of our auth_transform softcrypto abstraction, incorporation into the Open
Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX
accelerated OCF driver, blake2(4).
Optimized variants of blake2 are compiled for a number of x86 machines
(anything from SSE2 to AVX + XOP). On those machines, FPU context will need
to be explicitly saved before using blake2(4)-provided algorithms directly.
Use via cryptodev / OCF saves FPU state automatically, and use via the
auth_transform softcrypto abstraction does not use FPU.
The intent of the OCF driver is mostly to enable testing in userspace via
/dev/crypto. ATF tests are added with published KAT test vectors to
validate correctness.
Reviewed by: jhb, markj
Obtained from: github BLAKE2/libb2
Differential Revision: https://reviews.freebsd.org/D14662
2018-03-21 16:18:14 +00:00
|
|
|
${_blake2} \
|
2022-11-04 22:49:10 +00:00
|
|
|
${_bnxt} \
|
2006-07-26 22:10:10 +00:00
|
|
|
bridgestp \
|
2010-04-12 18:28:08 +00:00
|
|
|
bwi \
|
|
|
|
|
bwn \
|
2016-11-21 19:47:37 +00:00
|
|
|
${_bytgpio} \
|
2018-02-22 19:12:32 +00:00
|
|
|
${_chvgpio} \
|
2002-10-01 19:05:18 +00:00
|
|
|
cam \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_cardbus} \
|
2011-12-16 14:28:34 +00:00
|
|
|
${_carp} \
|
2009-06-15 18:22:41 +00:00
|
|
|
cas \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_cbb} \
|
2010-12-02 03:10:35 +00:00
|
|
|
cc \
|
2018-01-18 22:01:30 +00:00
|
|
|
${_ccp} \
|
2002-10-01 19:05:18 +00:00
|
|
|
cd9660 \
|
2003-09-26 20:26:25 +00:00
|
|
|
cd9660_iconv \
|
2011-12-30 03:48:39 +00:00
|
|
|
${_cfi} \
|
add iic interface to ig4 driver, move isl and cyapa to iicbus
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
|
|
|
${_chromebook_platform} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_ciss} \
|
2007-08-15 19:26:03 +00:00
|
|
|
${_coretemp} \
|
2012-08-15 06:31:32 +00:00
|
|
|
${_cpsw} \
|
2008-08-08 16:26:53 +00:00
|
|
|
${_cpuctl} \
|
2005-02-05 08:01:10 +00:00
|
|
|
${_cpufreq} \
|
2002-10-16 14:31:34 +00:00
|
|
|
${_crypto} \
|
|
|
|
|
${_cryptodev} \
|
2013-04-02 09:42:42 +00:00
|
|
|
ctl \
|
Make all the modules build on arm (modulo ipfilter, which I'm looking
into):
o Don't build vpo and syscons on mips or arm either
o Add a section for mips and arm breakages, and document why.
This is easier than opting in on all the other architectures:
# no BUS_SPACE_UNSPECIFIED: bce, bwi, bwn, mfi, mpt, siba_bwn
# No barrier instruction support (specific to this driver): sym
# no uart_cpu_$MACHINE_ARCH: uart
(mips has, by inspection, the same issues as arm, so ditto for it)
MFC after: 7 days
2010-03-29 17:31:55 +00:00
|
|
|
${_cxgb} \
|
2013-07-01 22:21:42 +00:00
|
|
|
${_cxgbe} \
|
2001-07-15 04:55:37 +00:00
|
|
|
dc \
|
2003-10-24 15:44:10 +00:00
|
|
|
dcons \
|
|
|
|
|
dcons_crom \
|
Add initial DPAA2 support
DPAA2 is a hardware-level networking architecture found in some NXP
SoCs which contain hardware blocks including Management Complex
(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O
processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer
pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify an
access to the underlying hardware. Each DPAA2 object has its own
driver (to perform an initialization at least) and will be visible
as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in
order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX)
dpaa2_mcX
dpaa2_rcX
dpaa2_mcp0
...
dpaa2_mcpN
dpaa2_bpX
dpaa2_macX
dpaa2_io0
...
dpaa2_ioM
dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI
and FDT flavours and implements helper interfaces to allocate and
assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some
of the objects as resources for the other DPAA2 objects to let them
function properly). Almost all of the DPAA2 objects are assigned to
the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface
to be operational. It is the most complex object in terms of
dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor)
Tested by: manu, bz
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36638
2022-09-20 09:47:41 +00:00
|
|
|
${_dpaa2} \
|
2021-01-09 12:08:00 +00:00
|
|
|
${_dpdk_lpm4} \
|
|
|
|
|
${_dpdk_lpm6} \
|
2008-08-23 21:00:40 +00:00
|
|
|
${_dpms} \
|
2001-10-05 07:09:27 +00:00
|
|
|
dummynet \
|
2021-01-13 17:23:51 +00:00
|
|
|
${_dwwdt} \
|
2021-09-13 09:42:16 +00:00
|
|
|
${_e6000sw} \
|
Add kernel interfaces to call EFI Runtime Services.
Runtime services require special execution environment for the call.
Besides that, OS must inform firmware about runtime virtual memory map
which will be active during the calls, with the SetVirtualAddressMap()
runtime call, done while the 1:1 mapping is still used. There are two
complication: the SetVirtualAddressMap() effectively must be done from
loader, which needs to know kernel address map in advance. More,
despite not explicitely mentioned in the specification, both 1:1 and
the map passed to SetVirtualAddressMap() must be active during the
SetVirtualAddressMap() call. Second, there are buggy BIOSes which
require both mappings active during runtime calls as well, most likely
because they fail to identify all relocations to perform.
On amd64, we can get rid of both problems by providing 1:1 mapping for
the duration of runtime calls, by temprorary remapping user addresses.
As result, we avoid the need for loader to know about future kernel
address map, and avoid bugs in BIOSes. Typically BIOS only maps
something in low 4G. If not runtime bugs, we would take advantage of
the DMAP, as previous versions of this patch did.
Similar but more complicated trick can be used even for i386 and 32bit
runtime, if and when the EFI boot on i386 is supported. We would need
a trampoline page, since potentially whole 4G of VA would be switched
on calls, instead of only userspace portion on amd64.
Context switches are disabled for the duration of the call, FPU access
is granted, and interrupts are not disabled. The later is possible
because kernel is mapped during calls.
To test, the sysctl mib debug.efi_time is provided, setting it to 1
makes one call to EFI get_time() runtime service, on success the efitm
structure is printed to the control terminal. Load efirt.ko, or add
EFIRT option to the kernel config, to enable code.
Discussed with: emaste, imp
Tested by: emaste (mac, qemu)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
2016-09-21 11:31:58 +00:00
|
|
|
${_efirt} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_em} \
|
Add support for Amazon Elastic Network Adapter (ENA) NIC
ENA is a networking interface designed to make good use of modern CPU
features and system architectures.
The ENA device exposes a lightweight management interface with a
minimal set of memory mapped registers and extendable command set
through an Admin Queue.
The driver supports a range of ENA devices, is link-speed independent
(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has
a negotiated and extendable feature set.
Some ENA devices support SR-IOV. This driver is used for both the
SR-IOV Physical Function (PF) and Virtual Function (VF) devices.
ENA devices enable high speed and low overhead network traffic
processing by providing multiple Tx/Rx queue pairs (the maximum number
is advertised by the device via the Admin Queue), a dedicated MSI-X
interrupt vector per Tx/Rx queue pair, and CPU cacheline optimized
data placement.
The ENA driver supports industry standard TCP/IP offload features such
as checksum offload and TCP transmit segmentation offload (TSO).
Receive-side scaling (RSS) is supported for multi-core scaling.
The ENA driver and its corresponding devices implement health
monitoring mechanisms such as watchdog, enabling the device and driver
to recover in a manner transparent to the application, as well as
debug logs.
Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds. This feature will
be implemented for driver in future releases.
Submitted by: Michal Krawczyk <mk@semihalf.com>
Jakub Palider <jpa@semihalf.com>
Jan Medala <jan@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon.com Inc.
Differential revision: https://reviews.freebsd.org/D10427
2017-05-22 14:46:13 +00:00
|
|
|
${_ena} \
|
2023-01-27 23:46:17 +00:00
|
|
|
${_enic} \
|
2021-07-28 09:23:23 +00:00
|
|
|
${_enetc} \
|
2008-06-20 19:28:33 +00:00
|
|
|
${_et} \
|
2016-10-02 03:20:31 +00:00
|
|
|
evdev \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_exca} \
|
2015-03-26 14:55:22 +00:00
|
|
|
ext2fs \
|
2001-07-15 04:55:37 +00:00
|
|
|
fdc \
|
2002-10-21 00:38:18 +00:00
|
|
|
fdescfs \
|
2021-06-09 11:23:26 +00:00
|
|
|
${_felix} \
|
2017-06-10 23:45:26 +00:00
|
|
|
${_ffec} \
|
Introduce DXR as an IPv4 longest prefix matching / FIB module
DXR maintains compressed lookup structures with a trivial search
procedure. A two-stage trie is indexed by the more significant bits of
the search key (IPv4 address), while the remaining bits are used for
finding the next hop in a sorted array. The tradeoff between memory
footprint and search speed depends on the split between the trie and
the remaining binary search. The default of 20 bits of the key being
used for trie indexing yields good performance (see below) with
footprints of around 2.5 Bytes per prefix with current BGP snapshots.
Rebuilding lookup structures takes some time, which is compensated for by
batching several RIB change requests into a single FIB update, i.e. FIB
synchronization with the RIB may be delayed for a fraction of a second.
RIB to FIB synchronization, next-hop table housekeeping, and lockless
lookup capability is provided by the FIB_ALGO infrastructure.
DXR works well on modern CPUs with several MBytes of caches, especially
in VMs, where is outperforms other currently available IPv4 FIB
algorithms by a large margin.
Synthetic single-thread LPM throughput test method:
kldload test_lookup; kldload dpdk_lpm4; kldload fib_dxr
sysctl net.route.test.run_lps_rnd=N
sysctl net.route.test.run_lps_seq=N
where N is the number of randomly generated keys (IPv4 addresses) which
should be chosen so that each test iteration runs for several seconds.
Each reported score represents the best of three runs, in million
lookups per second (MLPS), for two bechmarks (RND & SEQ) with two FIBs:
host: single interface address, local subnet route + default route
BGP: snapshot from linx.routeviews.org, 887957 prefixes, 496 next hops
Bhyve VM on an Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 40.6 20.2 N/A N/A
radix4 7.8 3.8 1.2 0.6
radix4_lockless 18.0 9.0 1.6 0.8
dpdk_lpm4 14.4 5.0 14.6 5.0
dxr 70.3 34.7 43.0 19.5
Intel(R) Core(TM) i5-5300U CPU @ 2.30 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 47.0 23.1 N/A N/A
radix4 8.5 4.2 1.9 1.0
radix4_lockless 19.2 9.5 2.5 1.2
dpdk_lpm4 31.2 9.4 31.6 9.3
dxr 84.9 41.4 51.7 23.6
Intel(R) Core(TM) i7-4771 CPU @ 3.50 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 59.5 29.4 N/A N/A
radix4 10.8 5.5 2.5 1.3
radix4_lockless 24.7 12.0 3.1 1.6
dpdk_lpm4 29.1 9.0 30.2 9.1
dxr 101.3 49.9 69.8 32.5
AMD Ryzen 7 3700X 8-Core Processor @ 3.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 70.8 35.4 N/A N/A
radix4 14.4 7.2 2.8 1.4
radix4_lockless 30.2 15.1 3.7 1.8
dpdk_lpm4 29.9 9.0 30.0 8.9
dxr 163.3 81.5 99.5 44.4
AMD Ryzen 5 5600X 6-Core Processor @ 3.70 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 93.6 46.7 N/A N/A
radix4 18.9 9.3 4.3 2.1
radix4_lockless 37.2 18.6 5.3 2.7
dpdk_lpm4 51.8 15.1 51.6 14.9
dxr 218.2 103.3 114.0 49.0
Reviewed by: melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29821
2021-05-05 11:45:52 +00:00
|
|
|
${_fib_dxr} \
|
2016-06-01 15:19:49 +00:00
|
|
|
filemon \
|
2002-11-07 16:19:43 +00:00
|
|
|
firewire \
|
2006-01-29 02:52:42 +00:00
|
|
|
firmware \
|
2021-11-25 09:36:55 +00:00
|
|
|
flash \
|
2023-02-28 17:16:46 +00:00
|
|
|
${_ftgpio} \
|
2020-11-28 22:34:33 +00:00
|
|
|
${_ftwd} \
|
2019-03-20 21:48:43 +00:00
|
|
|
fusefs \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_fxp} \
|
o Revert the part of if_gem.c rev. 1.35 which added a call to gem_stop()
to gem_attach() as the former access softc members not yet initialized
at that time and gem_reset() actually is enough to stop the chip. [1]
o Revise the use of gem_bitwait(); add bus_barrier() calls before calling
gem_bitwait() to ensure the respective bit has been written before we
starting polling on it and poll for the right bits to change, f.e. even
though we only reset RX we have to actually wait for both GEM_RESET_RX
and GEM_RESET_TX to clear. Add some additional gem_bitwait() calls in
places we've been missing them according to the GEM documentation.
Along with this some excessive DELAYs, which probably only were added
because of bugs in gem_bitwait() and its use in the first place, as
well as as have of an gem_bitwait() reimplementation in gem_reset_tx()
were removed.
o Add gem_reset_rxdma() and use it to deal with GEM_MAC_RX_OVERFLOW errors
more gracefully as unlike gem_init_locked() it resets the RX DMA engine
only, causing no link loss and the FIFOs not to be cleared. Also use it
deal with GEM_INTR_RX_TAG_ERR errors, with previously were unhandled.
This was based on information obtained from the Linux GEM and OpenSolaris
ERI drivers.
o Turn on workarounds for silicon bugs in the Apple GMAC variants.
This was based on information obtained from the Darwin GMAC and Linux GEM
drivers.
o Turn on "infinite" (i.e. maximum 31 * 64 bytes in length) DMA bursts.
This greatly improves especially RX performance.
o Optimize the RX path, this consists of:
- kicking the receiver as soon as we've a spare descriptor in gem_rint()
again instead of just once after all the ready ones have been handled;
- kicking the receiver the right way, i.e. as outlined in the GEM
documentation in batches of 4 and by pointing it to the descriptor
after the last valid one;
- calling gem_rint() before gem_tint() in gem_intr() as gem_tint() may
take quite a while;
- doubling the size of the RX ring to 256 descriptors.
Overall the RX performance of a GEM in a 1GHz Sun Fire V210 was improved
from ~100Mbit/s to ~850Mbit/s.
o In gem_add_rxbuf() don't assign the newly allocated mbuf to rxs_mbuf
before calling bus_dmamap_load_mbuf_sg(), if bus_dmamap_load_mbuf_sg()
fails we'll free the newly allocated mbuf, unable to recycle the
previous one but a NULL pointer dereference instead.
o In gem_init_locked() honor the return value of gem_meminit().
o Simplify gem_ringsize() and dont' return garbage in the default case.
Based on OpenBSD.
o Don't turn on MAC control, MIF and PCS interrupts unless GEM_DEBUG is
defined as we don't need/use these interrupts for operation.
o In gem_start_locked() sync the DMA maps of the descriptor rings before
every kick of the transmitter and not just once after enqueuing all
packets as the NIC might instantly start transmitting after we kicked
it the first time.
o Keep state of the link state and use it to enable or disable the MAC
in gem_mii_statchg() accordingly as well as to return early from
gem_start_locked() in case the link is down. [3]
o Initialize the maximum frame size to a sane value.
o In gem_mii_statchg() enable carrier extension if appropriate.
o Increment if_ierrors in case of an GEM_MAC_RX_OVERFLOW error and in
gem_eint(). [3]
o Handle IFF_ALLMULTI correctly; don't set it if we've turned promiscuous
group mode on and don't clear the flag if we've disabled promiscuous
group mode (these were mostly NOPs though). [2]
o Let gem_eint() also report GEM_INTR_PERR errors.
o Move setting sc_variant from gem_pci_probe() to gem_pci_attach() as
device probe methods are not supposed to touch the softc.
o Collapse sc_inited and sc_pci into bits for sc_flags.
o Add CTASSERTs ensuring that GEM_NRXDESC and GEM_NTXDESC are set to
legal values.
o Correctly set up for 802.3x flow control, though #ifdef out the code
that actually enables it as this needs more testing and mainly a proper
framework to support it.
o Correct and add some conversions from hard-coded functions names to
__func__ which were borked or forgotten in if_gem.c rev. 1.42.
o Use PCIR_BAR instead of a homegrown macro.
o Replace sc_enaddr[6] with sc_enaddr[ETHER_ADDR_LEN].
o In gem_pci_attach() in case attaching fails release the resources in
the opposite order they were allocated.
o Make gem_reset() static to if_gem.c as it's not needed outside that
module.
o Remove the GEM_GIGABIT flag and the associated code; GEM_GIGABIT was
never set and the associated code was in the wrong place.
o Remove sc_mif_config; it was only used to cache the contents of the
respective register within gem_attach().
o Remove the #ifdef'ed out NetBSD/OpenBSD code for establishing a suspend
hook as it will never be used on FreeBSD.
o Also probe Apple Intrepid 2 GMAC and Apple Shasta GMAC, add support for
Apple K2 GMAC. Based on OpenBSD.
o Add support for Sun GBE/P cards, or in other words actually add support
for cards based on GEM to gem(4). This mainly consists of adding support
for the TBI of these chips. Along with this the PHY selection code was
rewritten to hardcode the PHY number for certain configurations as for
example the PHY of the on-board ERI of Blade 1000 shows up twice causing
no link as the second incarnation is isolated.
These changes were ported from OpenBSD with some additional improvements
and modulo some bugs.
o Add code to if_gem_pci.c allowing to read the MAC-address from the VPD on
systems without Open Firmware.
This is an improved version of my variant of the respective code in
if_hme_pci.c
o Now that gem(4) is MI enable it for all archs.
Pointed out by: yongari [1]
Suggested by: rwatson [2], yongari [3]
Tested on: i386 (GEM), powerpc (GMACs by marcel and yongari),
sparc64 (ERI and GEM)
Reviewed by: yongari
Approved by: re (kensmith)
2007-09-26 21:14:18 +00:00
|
|
|
gem \
|
2003-05-31 18:36:41 +00:00
|
|
|
geom \
|
2011-05-15 14:01:23 +00:00
|
|
|
${_glxiic} \
|
2008-08-09 14:52:31 +00:00
|
|
|
${_glxsb} \
|
2016-05-27 20:43:46 +00:00
|
|
|
gpio \
|
2020-10-04 22:21:08 +00:00
|
|
|
hid \
|
2002-10-04 20:42:36 +00:00
|
|
|
hifn \
|
2011-12-28 23:26:58 +00:00
|
|
|
${_hpt27xx} \
|
2007-05-09 15:55:45 +00:00
|
|
|
${_hptiop} \
|
2004-10-24 08:53:40 +00:00
|
|
|
${_hptmv} \
|
2013-07-06 07:49:41 +00:00
|
|
|
${_hptnr} \
|
2007-12-15 00:56:17 +00:00
|
|
|
${_hptrr} \
|
2005-04-20 22:03:33 +00:00
|
|
|
hwpmc \
|
2013-06-15 06:21:17 +00:00
|
|
|
${_hyperv} \
|
2015-03-26 14:55:22 +00:00
|
|
|
i2c \
|
2018-10-12 22:40:54 +00:00
|
|
|
${_iavf} \
|
2013-09-29 00:35:03 +00:00
|
|
|
${_ibcore} \
|
2004-05-11 18:21:38 +00:00
|
|
|
${_ichwd} \
|
2020-05-26 23:35:10 +00:00
|
|
|
${_ice} \
|
|
|
|
|
${_ice_ddp} \
|
2022-05-23 23:39:27 +00:00
|
|
|
${_irdma} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_ida} \
|
2005-06-05 03:32:53 +00:00
|
|
|
if_bridge \
|
2022-04-02 16:53:37 +00:00
|
|
|
${_if_cgem} \
|
2001-07-15 04:55:37 +00:00
|
|
|
if_disc \
|
2007-03-26 04:39:18 +00:00
|
|
|
if_edsc \
|
2015-11-25 07:31:59 +00:00
|
|
|
${_if_enc} \
|
2009-07-26 12:20:07 +00:00
|
|
|
if_epair \
|
2014-11-07 19:13:19 +00:00
|
|
|
${_if_gif} \
|
2011-04-30 17:59:54 +00:00
|
|
|
${_if_gre} \
|
2014-11-07 19:13:19 +00:00
|
|
|
${_if_me} \
|
2020-10-22 09:09:53 +00:00
|
|
|
if_infiniband \
|
2007-04-17 00:35:11 +00:00
|
|
|
if_lagg \
|
2022-02-22 09:21:38 +00:00
|
|
|
if_ovpn \
|
2015-07-30 10:26:43 +00:00
|
|
|
${_if_stf} \
|
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.
(MFC commentary)
This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.
I have no plans to do this MFC as of now.
Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
|
|
|
if_tuntap \
|
2001-09-05 23:47:46 +00:00
|
|
|
if_vlan \
|
2014-10-20 14:42:42 +00:00
|
|
|
if_vxlan \
|
2022-10-28 20:36:12 +00:00
|
|
|
${_if_wg} \
|
2019-01-31 19:05:56 +00:00
|
|
|
iflib \
|
2021-07-12 04:50:15 +00:00
|
|
|
${_igc} \
|
2014-05-22 05:04:40 +00:00
|
|
|
imgact_binmisc \
|
2016-12-27 22:37:24 +00:00
|
|
|
${_intelspi} \
|
2004-08-01 11:40:54 +00:00
|
|
|
${_io} \
|
2015-08-24 19:32:03 +00:00
|
|
|
${_ioat} \
|
2013-09-29 00:35:03 +00:00
|
|
|
${_ipoib} \
|
2022-09-07 03:54:57 +00:00
|
|
|
ipdivert \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_ipfilter} \
|
2011-11-04 16:24:19 +00:00
|
|
|
${_ipfw} \
|
2008-02-29 22:28:18 +00:00
|
|
|
ipfw_nat \
|
2016-08-13 16:09:49 +00:00
|
|
|
${_ipfw_nat64} \
|
2016-07-18 19:46:31 +00:00
|
|
|
${_ipfw_nptv6} \
|
2017-04-03 03:07:48 +00:00
|
|
|
${_ipfw_pmod} \
|
2006-02-13 17:56:24 +00:00
|
|
|
${_ipmi} \
|
2012-11-20 14:11:27 +00:00
|
|
|
ip6_mroute_mod \
|
2007-10-15 08:26:12 +00:00
|
|
|
ip_mroute_mod \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_ips} \
|
2017-02-06 08:49:57 +00:00
|
|
|
${_ipsec} \
|
2006-03-15 20:58:44 +00:00
|
|
|
${_ipw} \
|
2007-03-02 11:42:56 +00:00
|
|
|
${_ipwfw} \
|
2012-01-31 19:38:18 +00:00
|
|
|
${_isci} \
|
2016-05-27 11:39:08 +00:00
|
|
|
${_iser} \
|
2002-10-31 19:50:18 +00:00
|
|
|
isp \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_ispfw} \
|
2019-10-16 15:01:44 +00:00
|
|
|
${_itwd} \
|
2006-03-15 20:58:44 +00:00
|
|
|
${_iwi} \
|
2007-03-02 11:42:56 +00:00
|
|
|
${_iwifw} \
|
2021-12-27 18:46:04 +00:00
|
|
|
${_iwlwifi} \
|
|
|
|
|
${_iwlwififw} \
|
2015-08-08 21:09:41 +00:00
|
|
|
${_iwm} \
|
|
|
|
|
${_iwmfw} \
|
2008-04-29 21:36:17 +00:00
|
|
|
${_iwn} \
|
|
|
|
|
${_iwnfw} \
|
2015-03-17 22:40:50 +00:00
|
|
|
${_ix} \
|
|
|
|
|
${_ixv} \
|
2014-08-28 17:40:19 +00:00
|
|
|
${_ixl} \
|
2008-05-27 01:54:45 +00:00
|
|
|
jme \
|
2005-07-14 23:04:23 +00:00
|
|
|
kbdmux \
|
2011-06-19 22:08:55 +00:00
|
|
|
kgssapi \
|
|
|
|
|
kgssapi_krb5 \
|
2011-01-24 07:50:29 +00:00
|
|
|
khelp \
|
2008-03-27 11:54:20 +00:00
|
|
|
krpc \
|
2009-05-26 21:39:09 +00:00
|
|
|
ksyms \
|
2006-01-31 22:34:13 +00:00
|
|
|
le \
|
2001-07-15 04:55:37 +00:00
|
|
|
lge \
|
2005-05-06 14:47:54 +00:00
|
|
|
libalias \
|
2001-12-12 10:11:16 +00:00
|
|
|
libiconv \
|
2001-07-15 04:55:37 +00:00
|
|
|
libmchain \
|
2019-05-19 15:44:21 +00:00
|
|
|
lindebugfs \
|
2015-10-26 10:09:08 +00:00
|
|
|
linuxkpi \
|
2023-03-16 15:12:12 +00:00
|
|
|
linuxkpi_hdmi \
|
2021-12-26 18:52:51 +00:00
|
|
|
linuxkpi_wlan \
|
2017-09-12 23:36:58 +00:00
|
|
|
${_lio} \
|
2001-11-03 08:20:44 +00:00
|
|
|
lpt \
|
2022-06-14 16:07:30 +00:00
|
|
|
${_mac_biba} \
|
|
|
|
|
${_mac_bsdextended} \
|
mac: add new mac_ddb(4) policy
Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the system state, including sensitive data such as
signing keys.
However, having some access to debugger functionality on production
systems may be useful in determining the cause of a panic or hang.
Therefore, it is desirable to have an optional policy which allows
limited use of ddb(4) while disabling the functionality which could
reveal system secrets.
This loadable MAC module allows for the use of some ddb(4) commands
while preventing the execution of others. The commands have been broadly
grouped into three categories:
- Those which are 'safe' and will not emit sensitive data (e.g. trace).
Generally, these commands are deterministic and don't accept
arguments.
- Those which are definitively unsafe (e.g. examine <addr>, search
<addr> <value>)
- Commands which may be safe to execute depending on the arguments
provided (e.g. show thread <addr>).
Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag.
Commands requiring extra validation can provide a function to do so.
For example, 'show thread <addr>' can be used as long as addr can be
checked against the system's list of process structures.
The policy also prevents debugger backends other than ddb(4) from
executing, for example gdb(4).
Reviewed by: markj, pauamma_gundo.com (manpages)
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35371
2022-07-18 21:24:06 +00:00
|
|
|
${_mac_ddb} \
|
2022-06-14 16:07:30 +00:00
|
|
|
${_mac_ifoff} \
|
|
|
|
|
${_mac_lomac} \
|
|
|
|
|
${_mac_mls} \
|
|
|
|
|
${_mac_none} \
|
|
|
|
|
${_mac_ntpd} \
|
|
|
|
|
${_mac_partition} \
|
|
|
|
|
${_mac_pimd} \
|
|
|
|
|
${_mac_portacl} \
|
|
|
|
|
${_mac_priority} \
|
|
|
|
|
${_mac_seeotheruids} \
|
|
|
|
|
${_mac_stub} \
|
|
|
|
|
${_mac_test} \
|
2023-04-16 23:16:49 +00:00
|
|
|
${_mac_veriexec} \
|
|
|
|
|
${_mac_veriexec_sha1} \
|
|
|
|
|
${_mac_veriexec_sha256} \
|
|
|
|
|
${_mac_veriexec_sha384} \
|
|
|
|
|
${_mac_veriexec_sha512} \
|
2020-10-14 12:28:48 +00:00
|
|
|
${_malo} \
|
2021-08-20 08:43:10 +00:00
|
|
|
${_mana} \
|
2001-07-15 04:55:37 +00:00
|
|
|
md \
|
2015-12-26 02:31:39 +00:00
|
|
|
mdio \
|
2021-09-28 16:58:40 +00:00
|
|
|
${_mgb} \
|
2004-08-02 19:21:51 +00:00
|
|
|
mem \
|
2010-04-12 18:28:08 +00:00
|
|
|
mfi \
|
2001-07-15 04:55:37 +00:00
|
|
|
mii \
|
|
|
|
|
mlx \
|
2019-05-08 10:49:05 +00:00
|
|
|
mlxfw \
|
2011-03-21 21:35:19 +00:00
|
|
|
${_mlx4} \
|
|
|
|
|
${_mlx4ib} \
|
2016-09-30 08:23:06 +00:00
|
|
|
${_mlx4en} \
|
2015-11-19 12:55:43 +00:00
|
|
|
${_mlx5} \
|
|
|
|
|
${_mlx5en} \
|
2017-08-23 12:09:37 +00:00
|
|
|
${_mlx5ib} \
|
2017-07-09 20:42:11 +00:00
|
|
|
mmc \
|
|
|
|
|
mmcsd \
|
2018-12-09 06:06:06 +00:00
|
|
|
${_mpr} \
|
|
|
|
|
${_mps} \
|
2010-04-12 18:28:08 +00:00
|
|
|
mpt \
|
2005-11-26 12:46:01 +00:00
|
|
|
mqueue \
|
2014-05-07 16:16:49 +00:00
|
|
|
mrsas \
|
2002-10-06 08:07:40 +00:00
|
|
|
msdosfs \
|
2003-09-26 20:26:25 +00:00
|
|
|
msdosfs_iconv \
|
2006-12-13 02:37:48 +00:00
|
|
|
msk \
|
2018-02-13 17:04:34 +00:00
|
|
|
${_mthca} \
|
2010-05-02 19:28:30 +00:00
|
|
|
mvs \
|
2009-06-01 18:07:01 +00:00
|
|
|
mwl \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_mwlfw} \
|
2007-07-19 16:16:00 +00:00
|
|
|
mxge \
|
2003-02-27 14:49:56 +00:00
|
|
|
my \
|
2016-03-31 04:57:38 +00:00
|
|
|
${_nctgpio} \
|
2021-09-13 09:44:31 +00:00
|
|
|
${_neta} \
|
netlink: add netlink support
Netlinks is a communication protocol currently used in Linux kernel to modify,
read and subscribe for nearly all networking state. Interfaces, addresses, routes,
firewall, fibs, vnets, etc are controlled via netlink.
It is async, TLV-based protocol, providing 1-1 and 1-many communications.
The current implementation supports the subset of NETLINK_ROUTE
family. To be more specific, the following is supported:
* Dumps:
- routes
- nexthops / nexthop groups
- interfaces
- interface addresses
- neighbors (arp/ndp)
* Notifications:
- interface arrival/departure
- interface address arrival/departure
- route addition/deletion
* Modifications:
- adding/deleting routes
- adding/deleting nexthops/nexthops groups
- adding/deleting neghbors
- adding/deleting interfaces (basic support only)
* Rtsock interaction
- route events are bridged both ways
The implementation also supports the NETLINK_GENERIC family framework.
Implementation notes:
Netlink is implemented via loadable/unloadable kernel module,
not touching many kernel parts.
Each netlink socket uses dedicated taskqueue to support async operations
that can sleep, such as interface creation. All message processing is
performed within these taskqueues.
Compatibility:
Most of the Netlink data models specified above maps to FreeBSD concepts
nicely. Unmodified ip(8) binary correctly works with
interfaces, addresses, routes, nexthops and nexthop groups. Some
software such as net/bird require header-only modifications to compile
and work with FreeBSD netlink.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36002
MFC after: 2 months
2022-01-20 21:39:21 +00:00
|
|
|
netlink \
|
2010-01-16 17:08:22 +00:00
|
|
|
${_netgraph} \
|
2006-06-26 23:41:07 +00:00
|
|
|
${_nfe} \
|
2009-05-28 19:45:11 +00:00
|
|
|
nfscl \
|
|
|
|
|
nfscommon \
|
|
|
|
|
nfsd \
|
2008-03-27 11:54:20 +00:00
|
|
|
nfslockd \
|
2009-04-12 19:04:27 +00:00
|
|
|
nfssvc \
|
2001-07-15 04:55:37 +00:00
|
|
|
nge \
|
|
|
|
|
nmdm \
|
|
|
|
|
nullfs \
|
2013-04-29 22:48:53 +00:00
|
|
|
${_ntb} \
|
2012-09-17 19:26:33 +00:00
|
|
|
${_nvd} \
|
2018-10-16 20:12:35 +00:00
|
|
|
${_nvdimm} \
|
2012-09-17 19:26:33 +00:00
|
|
|
${_nvme} \
|
2007-10-26 03:23:54 +00:00
|
|
|
${_nvram} \
|
2012-02-10 21:03:04 +00:00
|
|
|
oce \
|
2018-03-30 15:28:25 +00:00
|
|
|
${_ocs_fc} \
|
2020-10-20 17:50:18 +00:00
|
|
|
${_ossl} \
|
2015-09-26 07:08:35 +00:00
|
|
|
otus \
|
2016-07-25 00:49:27 +00:00
|
|
|
${_otusfw} \
|
2015-08-27 23:33:38 +00:00
|
|
|
ow \
|
2005-08-18 00:30:22 +00:00
|
|
|
${_padlock} \
|
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.
This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.
The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.
The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.
Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.
My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.
My Nomex pants are on. Let the feedback commence!
Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?)
Approved by: so(des)
2014-10-30 21:21:53 +00:00
|
|
|
${_padlock_rng} \
|
2020-03-31 06:25:43 +00:00
|
|
|
${_pchtherm} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_pcfclock} \
|
2004-03-08 22:03:29 +00:00
|
|
|
${_pf} \
|
2006-02-05 17:17:32 +00:00
|
|
|
${_pflog} \
|
2011-06-28 11:57:25 +00:00
|
|
|
${_pfsync} \
|
2001-11-03 08:20:44 +00:00
|
|
|
plip \
|
2015-07-17 20:30:30 +00:00
|
|
|
${_pms} \
|
2001-11-03 08:20:44 +00:00
|
|
|
ppbus \
|
2006-06-18 05:05:46 +00:00
|
|
|
ppc \
|
2001-11-03 08:20:44 +00:00
|
|
|
ppi \
|
|
|
|
|
pps \
|
2002-02-04 20:16:50 +00:00
|
|
|
procfs \
|
2014-04-28 17:58:40 +00:00
|
|
|
proto \
|
2002-02-04 20:16:50 +00:00
|
|
|
pseudofs \
|
2005-01-27 11:07:13 +00:00
|
|
|
${_pst} \
|
2009-08-28 10:23:40 +00:00
|
|
|
pty \
|
2006-06-18 05:05:46 +00:00
|
|
|
puc \
|
2019-06-16 00:53:09 +00:00
|
|
|
pwm \
|
2022-07-19 08:15:34 +00:00
|
|
|
${_qat} \
|
2020-11-05 16:00:30 +00:00
|
|
|
${_qatfw} \
|
2022-08-04 13:37:55 +00:00
|
|
|
${_qat_c2xxx} \
|
|
|
|
|
${_qat_c2xxxfw} \
|
2013-06-25 17:50:22 +00:00
|
|
|
${_qlxge} \
|
2011-11-03 21:20:22 +00:00
|
|
|
${_qlxgb} \
|
2013-05-15 17:03:09 +00:00
|
|
|
${_qlxgbe} \
|
2017-04-04 06:16:59 +00:00
|
|
|
${_qlnx} \
|
2005-04-18 18:47:38 +00:00
|
|
|
ral \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_ralfw} \
|
2015-08-17 07:36:12 +00:00
|
|
|
${_random_fortuna} \
|
|
|
|
|
${_random_other} \
|
2003-01-15 20:06:38 +00:00
|
|
|
rc4 \
|
2008-05-05 20:41:54 +00:00
|
|
|
${_rdma} \
|
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.
This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.
The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.
The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.
Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.
My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.
My Nomex pants are on. Let the feedback commence!
Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?)
Approved by: so(des)
2014-10-30 21:21:53 +00:00
|
|
|
${_rdrand_rng} \
|
Take the support for the 8139C+/8169/8169S/8110S chips out of the
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
2003-09-08 02:11:25 +00:00
|
|
|
re \
|
2001-07-15 04:55:37 +00:00
|
|
|
rl \
|
2018-06-14 06:40:59 +00:00
|
|
|
${_rockchip} \
|
2020-11-24 21:28:44 +00:00
|
|
|
rtsx \
|
2022-03-30 22:36:03 +00:00
|
|
|
${_rtw88} \
|
|
|
|
|
${_rtw88fw} \
|
2015-12-31 22:33:32 +00:00
|
|
|
rtwn \
|
rtwn(4), urtwn(4): merge common code, add support for 11ac devices.
All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- multi-bss support:
* for RTL8821AU: 2 VAPs at the same time;
* other: 1 any VAP + 1 sta VAP.
RTL8188CE:
- fix IQ calibration bug (reason of significant speed degradation);
- add h/w crypto acceleration support.
USB:
- A-MPDU Tx support;
- short GI support;
Other:
- add support for RTL8812AU / RTL8821AU chipsets
(a/b/g/n only; no ac yet);
- split merged code into subparts:
* bus glue (usb/*, pci/*, rtl*/usb/*, rtl*/pci/*)
* common (if_rtwn*)
* chip-specific (rtl*/*)
- various other bugfixes.
Due to code reorganization, module names / requirements were changed too:
urtwn urtwnfw -> rtwn rtwn_usb rtwnfw
rtwn rtwnfw -> rtwn rtwn_pci rtwnfw
Tested with RTL8188CE, RTL8188CUS, RTL8188EU and RTL8821AU.
Tested by: kevlo, garga,
Peter Garshtja <peter.garshtja@ambient-md.com>,
Kevin McAleavey <kevin.mcaleavey@knosproject.com>,
Ilias-Dimitrios Vrachnis <id@vrachnis.com>,
<otacilio.neto@bsd.com.br>
Relnotes: yes
2016-10-17 20:38:24 +00:00
|
|
|
rtwn_pci \
|
|
|
|
|
rtwn_usb \
|
2016-01-04 19:04:33 +00:00
|
|
|
${_rtwnfw} \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_s3} \
|
|
|
|
|
${_safe} \
|
2020-07-14 14:09:29 +00:00
|
|
|
safexcel \
|
2008-09-10 18:36:58 +00:00
|
|
|
${_sbni} \
|
2006-03-30 18:39:24 +00:00
|
|
|
scc \
|
2020-07-10 14:56:05 +00:00
|
|
|
${_sctp} \
|
2008-10-21 20:33:40 +00:00
|
|
|
sdhci \
|
2017-01-11 01:53:54 +00:00
|
|
|
${_sdhci_acpi} \
|
2021-04-28 13:57:39 +00:00
|
|
|
${_sdhci_fdt} \
|
2012-10-16 01:10:43 +00:00
|
|
|
sdhci_pci \
|
2019-06-08 16:26:56 +00:00
|
|
|
sdio \
|
2006-11-11 16:49:29 +00:00
|
|
|
sem \
|
2010-08-19 11:31:03 +00:00
|
|
|
send \
|
2011-11-18 11:10:14 +00:00
|
|
|
${_sfxge} \
|
2010-04-14 20:45:33 +00:00
|
|
|
sge \
|
2017-08-16 10:38:06 +00:00
|
|
|
${_sgx} \
|
|
|
|
|
${_sgx_linux} \
|
2010-07-03 13:32:39 +00:00
|
|
|
siftr \
|
2009-07-21 12:32:46 +00:00
|
|
|
siis \
|
2001-07-15 04:55:37 +00:00
|
|
|
sis \
|
|
|
|
|
sk \
|
2018-04-26 16:59:06 +00:00
|
|
|
${_smartpqi} \
|
2015-03-26 14:55:22 +00:00
|
|
|
smbfs \
|
2008-11-05 15:04:03 +00:00
|
|
|
snp \
|
2015-03-26 14:55:22 +00:00
|
|
|
sound \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_speaker} \
|
2018-02-19 01:32:27 +00:00
|
|
|
spi \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_splash} \
|
2001-07-15 04:55:37 +00:00
|
|
|
ste \
|
2006-07-25 00:45:55 +00:00
|
|
|
stge \
|
2020-08-30 07:34:32 +00:00
|
|
|
${_sume} \
|
add superio driver
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.
I am planning to convert nctgpio and wbwd to superio bus very soon.
Also, I am working on itwd driver (watchdog in ITE SuperIO-s).
Additionally, there is ithwm driver based on the reverted sensors
import, but I am not sure how to integrate it given that we still lack
any sensors interface.
Discussed with: imp, jhb
MFC after: 7 weeks
Differential Revision: https://reviews.freebsd.org/D8175
2019-07-01 17:05:41 +00:00
|
|
|
${_superio} \
|
2021-06-29 13:54:07 +00:00
|
|
|
${_p2sb} \
|
2021-12-31 22:02:35 +00:00
|
|
|
sym \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_syscons} \
|
2001-07-15 04:55:37 +00:00
|
|
|
sysvipc \
|
2023-02-02 17:18:41 +00:00
|
|
|
tarfs \
|
2017-03-27 18:20:32 +00:00
|
|
|
tcp \
|
2012-02-04 00:54:43 +00:00
|
|
|
${_ti} \
|
2010-03-08 15:01:08 +00:00
|
|
|
tmpfs \
|
2012-06-19 07:34:13 +00:00
|
|
|
${_toecore} \
|
2010-08-12 22:46:31 +00:00
|
|
|
${_tpm} \
|
2011-10-04 21:40:25 +00:00
|
|
|
tws \
|
2010-04-13 21:32:06 +00:00
|
|
|
uart \
|
2002-04-14 16:36:49 +00:00
|
|
|
udf \
|
2003-11-07 09:38:05 +00:00
|
|
|
udf_iconv \
|
2009-07-05 15:25:02 +00:00
|
|
|
ufs \
|
2016-10-02 03:20:31 +00:00
|
|
|
uinput \
|
2001-07-15 04:55:37 +00:00
|
|
|
unionfs \
|
2009-02-23 18:32:59 +00:00
|
|
|
usb \
|
2004-01-16 15:55:29 +00:00
|
|
|
${_vesa} \
|
2021-01-21 01:21:35 +00:00
|
|
|
virtio \
|
2004-09-10 20:57:46 +00:00
|
|
|
vge \
|
2011-12-12 09:50:33 +00:00
|
|
|
${_viawd} \
|
2015-03-08 08:44:04 +00:00
|
|
|
videomode \
|
2004-11-16 17:19:04 +00:00
|
|
|
vkbd \
|
2019-10-10 03:12:17 +00:00
|
|
|
${_vmd} \
|
2011-05-13 04:54:01 +00:00
|
|
|
${_vmm} \
|
2013-08-23 20:47:16 +00:00
|
|
|
${_vmware} \
|
2001-07-15 04:55:37 +00:00
|
|
|
vr \
|
2010-12-31 00:21:41 +00:00
|
|
|
vte \
|
2012-03-06 18:44:52 +00:00
|
|
|
${_wbwd} \
|
2023-01-03 15:16:36 +00:00
|
|
|
${_wdatwd} \
|
2003-01-15 20:06:38 +00:00
|
|
|
wlan \
|
2005-03-09 15:53:27 +00:00
|
|
|
wlan_acl \
|
2006-11-26 19:55:26 +00:00
|
|
|
wlan_amrr \
|
2004-12-08 17:38:38 +00:00
|
|
|
wlan_ccmp \
|
2008-04-20 20:35:46 +00:00
|
|
|
wlan_rssadapt \
|
2004-12-08 17:38:38 +00:00
|
|
|
wlan_tkip \
|
|
|
|
|
wlan_wep \
|
|
|
|
|
wlan_xauth \
|
2007-11-08 22:09:37 +00:00
|
|
|
${_wpi} \
|
|
|
|
|
${_wpifw} \
|
2009-09-21 23:58:29 +00:00
|
|
|
${_x86bios} \
|
2020-04-17 06:04:20 +00:00
|
|
|
xdr \
|
2006-02-27 16:50:51 +00:00
|
|
|
xl \
|
2019-02-26 19:55:03 +00:00
|
|
|
xz \
|
2014-10-05 07:27:05 +00:00
|
|
|
zlib
|
2013-07-01 22:21:42 +00:00
|
|
|
|
2015-01-26 07:15:49 +00:00
|
|
|
.if ${MK_AUTOFS} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_autofs= autofs
|
|
|
|
|
.endif
|
|
|
|
|
|
2022-07-06 13:03:48 +00:00
|
|
|
.if ${MK_DTRACE} != "no" || defined(ALL_MODULES)
|
2020-02-16 15:43:28 +00:00
|
|
|
.if ${KERN_OPTS:MKDTRACE_HOOKS}
|
2015-10-23 12:59:54 +00:00
|
|
|
SUBDIR+= dtrace
|
|
|
|
|
.endif
|
|
|
|
|
SUBDIR+= opensolaris
|
|
|
|
|
.endif
|
|
|
|
|
|
2022-11-04 22:49:10 +00:00
|
|
|
# Requires bus_space_read_8
|
2022-11-05 04:35:37 +00:00
|
|
|
.if ${MACHINE_ARCH} != "i386"
|
2022-11-04 22:49:10 +00:00
|
|
|
_bnxt= bnxt
|
|
|
|
|
.endif
|
|
|
|
|
|
2006-03-17 18:54:44 +00:00
|
|
|
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
|
2017-03-04 10:10:17 +00:00
|
|
|
.if exists(${SRCTOP}/sys/opencrypto)
|
2004-01-16 15:55:29 +00:00
|
|
|
_crypto= crypto
|
|
|
|
|
_cryptodev= cryptodev
|
2015-08-17 07:36:12 +00:00
|
|
|
_random_fortuna=random_fortuna
|
|
|
|
|
_random_other= random_other
|
2004-01-16 15:55:29 +00:00
|
|
|
.endif
|
2002-03-21 09:15:39 +00:00
|
|
|
.endif
|
|
|
|
|
|
2015-01-25 05:13:15 +00:00
|
|
|
.if ${MK_CUSE} != "no" || defined(ALL_MODULES)
|
|
|
|
|
SUBDIR+= cuse
|
|
|
|
|
.endif
|
|
|
|
|
|
2020-07-19 23:19:09 +00:00
|
|
|
.if ${MK_EFI} != "no"
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64"
|
|
|
|
|
_efirt= efirt
|
|
|
|
|
.endif
|
|
|
|
|
.endif
|
|
|
|
|
|
2011-04-30 17:59:54 +00:00
|
|
|
.if (${MK_INET_SUPPORT} != "no" || ${MK_INET6_SUPPORT} != "no") || \
|
|
|
|
|
defined(ALL_MODULES)
|
2014-10-05 07:27:05 +00:00
|
|
|
_carp= carp
|
2012-06-19 07:34:13 +00:00
|
|
|
_toecore= toecore
|
2015-11-25 07:31:59 +00:00
|
|
|
_if_enc= if_enc
|
2014-11-07 19:13:19 +00:00
|
|
|
_if_gif= if_gif
|
|
|
|
|
_if_gre= if_gre
|
2022-10-28 20:36:12 +00:00
|
|
|
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_if_wg= if_wg
|
|
|
|
|
.endif
|
2017-04-03 03:07:48 +00:00
|
|
|
_ipfw_pmod= ipfw_pmod
|
2020-06-02 00:32:36 +00:00
|
|
|
.if ${KERN_OPTS:MIPSEC_SUPPORT} && !${KERN_OPTS:MIPSEC}
|
2017-02-06 08:49:57 +00:00
|
|
|
_ipsec= ipsec
|
|
|
|
|
.endif
|
2020-07-10 14:56:05 +00:00
|
|
|
.if ${KERN_OPTS:MSCTP_SUPPORT} || ${KERN_OPTS:MSCTP}
|
|
|
|
|
_sctp= sctp
|
|
|
|
|
.endif
|
2011-04-30 17:59:54 +00:00
|
|
|
.endif
|
|
|
|
|
|
2015-07-30 10:26:43 +00:00
|
|
|
.if (${MK_INET_SUPPORT} != "no" && ${MK_INET6_SUPPORT} != "no") || \
|
|
|
|
|
defined(ALL_MODULES)
|
|
|
|
|
_if_stf= if_stf
|
|
|
|
|
.endif
|
|
|
|
|
|
2012-01-22 02:16:31 +00:00
|
|
|
.if ${MK_INET_SUPPORT} != "no" || defined(ALL_MODULES)
|
2014-11-07 19:13:19 +00:00
|
|
|
_if_me= if_me
|
2014-10-05 07:27:05 +00:00
|
|
|
_ipfw= ipfw
|
2016-08-13 16:09:49 +00:00
|
|
|
.if ${MK_INET6_SUPPORT} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_ipfw_nat64= ipfw_nat64
|
|
|
|
|
.endif
|
2012-01-22 02:16:31 +00:00
|
|
|
.endif
|
|
|
|
|
|
2016-07-18 19:46:31 +00:00
|
|
|
.if ${MK_INET6_SUPPORT} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_ipfw_nptv6= ipfw_nptv6
|
|
|
|
|
.endif
|
|
|
|
|
|
2006-03-17 18:54:44 +00:00
|
|
|
.if ${MK_IPFILTER} != "no" || defined(ALL_MODULES)
|
2004-01-16 15:55:29 +00:00
|
|
|
_ipfilter= ipfilter
|
2002-10-21 00:38:18 +00:00
|
|
|
.endif
|
|
|
|
|
|
2021-01-09 12:08:00 +00:00
|
|
|
.if ${MK_INET_SUPPORT} != "no" && ${KERN_OPTS:MFIB_ALGO}
|
|
|
|
|
_dpdk_lpm4= dpdk_lpm4
|
Introduce DXR as an IPv4 longest prefix matching / FIB module
DXR maintains compressed lookup structures with a trivial search
procedure. A two-stage trie is indexed by the more significant bits of
the search key (IPv4 address), while the remaining bits are used for
finding the next hop in a sorted array. The tradeoff between memory
footprint and search speed depends on the split between the trie and
the remaining binary search. The default of 20 bits of the key being
used for trie indexing yields good performance (see below) with
footprints of around 2.5 Bytes per prefix with current BGP snapshots.
Rebuilding lookup structures takes some time, which is compensated for by
batching several RIB change requests into a single FIB update, i.e. FIB
synchronization with the RIB may be delayed for a fraction of a second.
RIB to FIB synchronization, next-hop table housekeeping, and lockless
lookup capability is provided by the FIB_ALGO infrastructure.
DXR works well on modern CPUs with several MBytes of caches, especially
in VMs, where is outperforms other currently available IPv4 FIB
algorithms by a large margin.
Synthetic single-thread LPM throughput test method:
kldload test_lookup; kldload dpdk_lpm4; kldload fib_dxr
sysctl net.route.test.run_lps_rnd=N
sysctl net.route.test.run_lps_seq=N
where N is the number of randomly generated keys (IPv4 addresses) which
should be chosen so that each test iteration runs for several seconds.
Each reported score represents the best of three runs, in million
lookups per second (MLPS), for two bechmarks (RND & SEQ) with two FIBs:
host: single interface address, local subnet route + default route
BGP: snapshot from linx.routeviews.org, 887957 prefixes, 496 next hops
Bhyve VM on an Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 40.6 20.2 N/A N/A
radix4 7.8 3.8 1.2 0.6
radix4_lockless 18.0 9.0 1.6 0.8
dpdk_lpm4 14.4 5.0 14.6 5.0
dxr 70.3 34.7 43.0 19.5
Intel(R) Core(TM) i5-5300U CPU @ 2.30 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 47.0 23.1 N/A N/A
radix4 8.5 4.2 1.9 1.0
radix4_lockless 19.2 9.5 2.5 1.2
dpdk_lpm4 31.2 9.4 31.6 9.3
dxr 84.9 41.4 51.7 23.6
Intel(R) Core(TM) i7-4771 CPU @ 3.50 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 59.5 29.4 N/A N/A
radix4 10.8 5.5 2.5 1.3
radix4_lockless 24.7 12.0 3.1 1.6
dpdk_lpm4 29.1 9.0 30.2 9.1
dxr 101.3 49.9 69.8 32.5
AMD Ryzen 7 3700X 8-Core Processor @ 3.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 70.8 35.4 N/A N/A
radix4 14.4 7.2 2.8 1.4
radix4_lockless 30.2 15.1 3.7 1.8
dpdk_lpm4 29.9 9.0 30.0 8.9
dxr 163.3 81.5 99.5 44.4
AMD Ryzen 5 5600X 6-Core Processor @ 3.70 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 93.6 46.7 N/A N/A
radix4 18.9 9.3 4.3 2.1
radix4_lockless 37.2 18.6 5.3 2.7
dpdk_lpm4 51.8 15.1 51.6 14.9
dxr 218.2 103.3 114.0 49.0
Reviewed by: melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29821
2021-05-05 11:45:52 +00:00
|
|
|
_fib_dxr= fib_dxr
|
2021-01-09 12:08:00 +00:00
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
.if ${MK_INET6_SUPPORT} != "no" && ${KERN_OPTS:MFIB_ALGO}
|
|
|
|
|
_dpdk_lpm6= dpdk_lpm6
|
|
|
|
|
.endif
|
|
|
|
|
|
2015-01-25 04:20:11 +00:00
|
|
|
.if ${MK_ISCSI} != "no" || defined(ALL_MODULES)
|
2017-03-30 04:56:27 +00:00
|
|
|
SUBDIR+= cfiscsi
|
2015-01-25 04:20:11 +00:00
|
|
|
SUBDIR+= iscsi
|
|
|
|
|
.endif
|
|
|
|
|
|
2019-03-01 02:31:43 +00:00
|
|
|
.if !empty(OPT_FDT)
|
|
|
|
|
SUBDIR+= fdt
|
|
|
|
|
.endif
|
|
|
|
|
|
2019-09-12 18:14:44 +00:00
|
|
|
# Linuxulator
|
2018-06-26 19:13:49 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
|
2018-06-26 16:50:41 +00:00
|
|
|
${MACHINE_CPUARCH} == "i386"
|
|
|
|
|
SUBDIR+= linprocfs
|
|
|
|
|
SUBDIR+= linsysfs
|
2019-09-12 18:14:44 +00:00
|
|
|
.endif
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
|
|
|
|
|
SUBDIR+= linux
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64"
|
|
|
|
|
SUBDIR+= linux64
|
|
|
|
|
SUBDIR+= linux_common
|
|
|
|
|
.endif
|
|
|
|
|
|
2023-03-08 23:07:11 +00:00
|
|
|
.if ${MACHINE_CPUARCH} != "arm"
|
2019-04-23 15:11:01 +00:00
|
|
|
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_ibcore= ibcore
|
|
|
|
|
_ipoib= ipoib
|
|
|
|
|
_iser= iser
|
2023-03-08 23:07:11 +00:00
|
|
|
_mthca= mthca
|
|
|
|
|
_rdma= rdma
|
2019-04-23 15:11:01 +00:00
|
|
|
.endif
|
2023-03-08 23:07:11 +00:00
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
|
2023-03-08 23:12:25 +00:00
|
|
|
${MACHINE_CPUARCH} == "i386" || ${MACHINE_ARCH:Mpowerpc64*} != ""
|
2021-01-06 20:27:40 +00:00
|
|
|
_ipmi= ipmi
|
2019-04-23 15:11:01 +00:00
|
|
|
_mlx4= mlx4
|
|
|
|
|
_mlx5= mlx5
|
|
|
|
|
.if (${MK_INET_SUPPORT} != "no" && ${MK_INET6_SUPPORT} != "no") || \
|
|
|
|
|
defined(ALL_MODULES)
|
|
|
|
|
_mlx4en= mlx4en
|
|
|
|
|
_mlx5en= mlx5en
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_mlx4ib= mlx4ib
|
|
|
|
|
_mlx5ib= mlx5ib
|
|
|
|
|
.endif
|
2023-03-08 23:12:25 +00:00
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
|
|
|
|
|
${MACHINE_CPUARCH} == "i386"
|
|
|
|
|
_ena= ena
|
|
|
|
|
_iwlwifi= iwlwifi
|
|
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_iwlwififw= iwlwififw
|
|
|
|
|
.endif
|
2020-12-04 21:12:17 +00:00
|
|
|
_ossl= ossl
|
2022-03-30 22:36:03 +00:00
|
|
|
_rtw88= rtw88
|
|
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_rtw88fw= rtw88fw
|
|
|
|
|
.endif
|
2020-10-19 20:43:29 +00:00
|
|
|
_vmware= vmware
|
2018-06-26 16:50:41 +00:00
|
|
|
.endif
|
|
|
|
|
|
2022-06-14 16:07:30 +00:00
|
|
|
# MAC framework
|
|
|
|
|
.if ${KERN_OPTS:MMAC} || defined(ALL_MODULES)
|
|
|
|
|
_mac_biba= mac_biba
|
|
|
|
|
_mac_bsdextended= mac_bsdextended
|
mac: add new mac_ddb(4) policy
Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the system state, including sensitive data such as
signing keys.
However, having some access to debugger functionality on production
systems may be useful in determining the cause of a panic or hang.
Therefore, it is desirable to have an optional policy which allows
limited use of ddb(4) while disabling the functionality which could
reveal system secrets.
This loadable MAC module allows for the use of some ddb(4) commands
while preventing the execution of others. The commands have been broadly
grouped into three categories:
- Those which are 'safe' and will not emit sensitive data (e.g. trace).
Generally, these commands are deterministic and don't accept
arguments.
- Those which are definitively unsafe (e.g. examine <addr>, search
<addr> <value>)
- Commands which may be safe to execute depending on the arguments
provided (e.g. show thread <addr>).
Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag.
Commands requiring extra validation can provide a function to do so.
For example, 'show thread <addr>' can be used as long as addr can be
checked against the system's list of process structures.
The policy also prevents debugger backends other than ddb(4) from
executing, for example gdb(4).
Reviewed by: markj, pauamma_gundo.com (manpages)
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35371
2022-07-18 21:24:06 +00:00
|
|
|
.if ${KERN_OPTS:MDDB} || defined(ALL_MODULES)
|
|
|
|
|
_mac_ddb= mac_ddb
|
|
|
|
|
.endif
|
2022-06-14 16:07:30 +00:00
|
|
|
_mac_ifoff= mac_ifoff
|
|
|
|
|
_mac_lomac= mac_lomac
|
|
|
|
|
_mac_mls= mac_mls
|
|
|
|
|
_mac_none= mac_none
|
|
|
|
|
_mac_ntpd= mac_ntpd
|
|
|
|
|
_mac_partition= mac_partition
|
|
|
|
|
_mac_pimd= mac_pimd
|
|
|
|
|
_mac_portacl= mac_portacl
|
|
|
|
|
_mac_priority= mac_priority
|
|
|
|
|
_mac_seeotheruids= mac_seeotheruids
|
|
|
|
|
_mac_stub= mac_stub
|
|
|
|
|
_mac_test= mac_test
|
2023-04-16 23:36:07 +00:00
|
|
|
.if ${MK_VERIEXEC} != "no" || defined(ALL_MODULES)
|
2023-04-16 23:16:49 +00:00
|
|
|
_mac_veriexec= mac_veriexec
|
|
|
|
|
_mac_veriexec_sha1= mac_veriexec_sha1
|
|
|
|
|
_mac_veriexec_sha256= mac_veriexec_sha256
|
|
|
|
|
_mac_veriexec_sha384= mac_veriexec_sha384
|
|
|
|
|
_mac_veriexec_sha512= mac_veriexec_sha512
|
2022-06-14 16:07:30 +00:00
|
|
|
.endif
|
2023-04-16 23:36:07 +00:00
|
|
|
.endif
|
2022-06-14 16:07:30 +00:00
|
|
|
|
2010-01-16 17:08:22 +00:00
|
|
|
.if ${MK_NETGRAPH} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_netgraph= netgraph
|
|
|
|
|
.endif
|
|
|
|
|
|
2011-04-30 17:59:54 +00:00
|
|
|
.if (${MK_PF} != "no" && (${MK_INET_SUPPORT} != "no" || \
|
|
|
|
|
${MK_INET6_SUPPORT} != "no")) || defined(ALL_MODULES)
|
2004-03-08 22:03:29 +00:00
|
|
|
_pf= pf
|
2006-02-05 17:17:32 +00:00
|
|
|
_pflog= pflog
|
2011-06-28 11:57:25 +00:00
|
|
|
.if ${MK_INET_SUPPORT} != "no"
|
|
|
|
|
_pfsync= pfsync
|
|
|
|
|
.endif
|
2004-03-08 22:03:29 +00:00
|
|
|
.endif
|
|
|
|
|
|
2012-02-04 00:54:43 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_bce= bce
|
|
|
|
|
_fxp= fxp
|
|
|
|
|
_ispfw= ispfw
|
2017-01-26 18:05:31 +00:00
|
|
|
_ti= ti
|
2012-02-04 00:54:43 +00:00
|
|
|
_mwlfw= mwlfw
|
2016-07-25 00:49:27 +00:00
|
|
|
_otusfw= otusfw
|
2012-02-04 00:54:43 +00:00
|
|
|
_ralfw= ralfw
|
2016-01-04 19:04:33 +00:00
|
|
|
_rtwnfw= rtwnfw
|
2017-01-26 18:05:31 +00:00
|
|
|
.endif
|
2012-02-04 00:54:43 +00:00
|
|
|
|
2015-01-16 01:39:24 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
|
Create a new MACHINE_ARCH for Freescale PowerPC e500v2
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
|
|
|
${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspe" && \
|
|
|
|
|
${MACHINE_CPUARCH} != "riscv"
|
2014-12-31 20:34:12 +00:00
|
|
|
_cxgbe= cxgbe
|
|
|
|
|
.endif
|
2014-10-05 07:27:05 +00:00
|
|
|
|
2022-01-20 21:32:02 +00:00
|
|
|
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm64" || ${MACHINE_ARCH:Mpowerpc64*}
|
2020-05-26 23:35:10 +00:00
|
|
|
_ice= ice
|
|
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_ice_ddp= ice_ddp
|
|
|
|
|
.endif
|
2022-05-23 23:39:27 +00:00
|
|
|
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
|
2022-05-30 20:47:32 +00:00
|
|
|
.if ${MK_INET_SUPPORT} != "no" && ${MK_INET6_SUPPORT} != "no"
|
2022-05-23 23:39:27 +00:00
|
|
|
_irdma= irdma
|
|
|
|
|
.endif
|
2020-05-26 23:35:10 +00:00
|
|
|
.endif
|
2022-05-30 20:47:32 +00:00
|
|
|
.endif
|
2020-05-26 23:35:10 +00:00
|
|
|
|
2022-04-02 16:53:37 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "arm" || \
|
|
|
|
|
${MACHINE_CPUARCH} == "riscv"
|
2022-10-27 17:01:44 +00:00
|
|
|
.if !empty(OPT_FDT)
|
2022-04-02 16:53:37 +00:00
|
|
|
_if_cgem= if_cgem
|
|
|
|
|
.endif
|
2022-10-27 17:01:44 +00:00
|
|
|
.endif
|
2022-04-02 16:53:37 +00:00
|
|
|
|
2018-12-09 06:06:06 +00:00
|
|
|
# These rely on 64bit atomics
|
2021-12-31 22:02:35 +00:00
|
|
|
.if ${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspe"
|
2018-12-09 06:06:06 +00:00
|
|
|
_mps= mps
|
|
|
|
|
_mpr= mpr
|
|
|
|
|
.endif
|
|
|
|
|
|
2017-05-09 04:59:05 +00:00
|
|
|
.if ${MK_TESTS} != "no" || defined(ALL_MODULES)
|
2023-04-17 10:45:47 +00:00
|
|
|
SUBDIR+= ktest
|
2017-05-09 04:59:05 +00:00
|
|
|
SUBDIR+= tests
|
|
|
|
|
.endif
|
|
|
|
|
|
2023-03-12 06:20:11 +00:00
|
|
|
.if ${MK_ZFS} != "no" || defined(ALL_MODULES)
|
2015-10-23 12:59:54 +00:00
|
|
|
SUBDIR+= zfs
|
|
|
|
|
.endif
|
|
|
|
|
|
2014-10-05 07:27:05 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_cxgb= cxgb
|
|
|
|
|
.endif
|
|
|
|
|
|
2015-11-07 04:49:39 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64"
|
2016-11-21 11:18:00 +00:00
|
|
|
_armv8crypto= armv8crypto
|
Add initial DPAA2 support
DPAA2 is a hardware-level networking architecture found in some NXP
SoCs which contain hardware blocks including Management Complex
(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O
processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer
pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify an
access to the underlying hardware. Each DPAA2 object has its own
driver (to perform an initialization at least) and will be visible
as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in
order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX)
dpaa2_mcX
dpaa2_rcX
dpaa2_mcp0
...
dpaa2_mcpN
dpaa2_bpX
dpaa2_macX
dpaa2_io0
...
dpaa2_ioM
dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI
and FDT flavours and implements helper interfaces to allocate and
assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some
of the objects as resources for the other DPAA2 objects to let them
function properly). Almost all of the DPAA2 objects are assigned to
the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface
to be operational. It is the most complex object in terms of
dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor)
Tested by: manu, bz
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36638
2022-09-20 09:47:41 +00:00
|
|
|
_dpaa2= dpaa2
|
2015-11-07 04:49:39 +00:00
|
|
|
_em= em
|
2022-10-28 17:46:48 +00:00
|
|
|
_hyperv= hyperv
|
2022-10-27 17:01:44 +00:00
|
|
|
|
|
|
|
|
.if !empty(OPT_FDT)
|
|
|
|
|
_allwinner= allwinner
|
|
|
|
|
_dwwdt= dwwdt
|
2021-07-28 09:23:23 +00:00
|
|
|
_enetc= enetc
|
2021-06-09 11:23:26 +00:00
|
|
|
_felix= felix
|
2018-06-14 06:40:59 +00:00
|
|
|
_rockchip= rockchip
|
2015-11-07 04:49:39 +00:00
|
|
|
.endif
|
2022-10-27 17:01:44 +00:00
|
|
|
.endif
|
2015-11-07 04:49:39 +00:00
|
|
|
|
2021-05-13 18:23:59 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "arm"
|
2022-10-27 17:01:44 +00:00
|
|
|
.if !empty(OPT_FDT)
|
2021-05-13 18:23:59 +00:00
|
|
|
_sdhci_fdt= sdhci_fdt
|
2022-10-27 17:01:44 +00:00
|
|
|
.endif
|
2021-09-13 09:42:16 +00:00
|
|
|
_e6000sw= e6000sw
|
2021-09-13 09:44:31 +00:00
|
|
|
_neta= neta
|
2022-10-27 19:18:52 +00:00
|
|
|
.endif
|
2021-05-13 18:23:59 +00:00
|
|
|
|
2014-10-05 07:27:05 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
|
2004-01-16 15:55:29 +00:00
|
|
|
_agp= agp
|
2021-12-06 23:11:10 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "i386" || !empty(COMPAT_FREEBSD32_ENABLED)
|
2004-01-16 15:55:29 +00:00
|
|
|
_aout= aout
|
2021-12-06 23:11:10 +00:00
|
|
|
.endif
|
2016-12-03 17:54:08 +00:00
|
|
|
_bios= bios
|
2017-08-19 00:45:29 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
2011-04-25 21:53:41 +00:00
|
|
|
_bxe= bxe
|
2017-08-19 00:45:29 +00:00
|
|
|
.endif
|
2005-09-27 13:10:24 +00:00
|
|
|
_cardbus= cardbus
|
|
|
|
|
_cbb= cbb
|
2008-08-08 16:26:53 +00:00
|
|
|
_cpuctl= cpuctl
|
2005-02-05 08:01:10 +00:00
|
|
|
_cpufreq= cpufreq
|
2008-08-23 21:00:40 +00:00
|
|
|
_dpms= dpms
|
2004-01-16 15:55:29 +00:00
|
|
|
_em= em
|
2008-06-20 19:28:33 +00:00
|
|
|
_et= et
|
2023-02-28 17:16:46 +00:00
|
|
|
_ftgpio= ftgpio
|
2020-11-28 22:34:33 +00:00
|
|
|
_ftwd= ftwd
|
2005-09-27 13:10:24 +00:00
|
|
|
_exca= exca
|
2021-07-12 04:50:15 +00:00
|
|
|
_igc= igc
|
2004-08-01 11:40:54 +00:00
|
|
|
_io= io
|
2019-10-16 15:01:44 +00:00
|
|
|
_itwd= itwd
|
2015-06-24 15:53:52 +00:00
|
|
|
_ix= ix
|
2015-03-18 16:54:03 +00:00
|
|
|
_ixv= ixv
|
2017-10-25 17:49:17 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_lio= lio
|
|
|
|
|
.endif
|
2021-08-20 08:43:10 +00:00
|
|
|
_mana= mana
|
2021-09-28 16:58:40 +00:00
|
|
|
_mgb= mgb
|
2016-03-31 04:57:38 +00:00
|
|
|
_nctgpio= nctgpio
|
2019-08-15 16:27:04 +00:00
|
|
|
_ntb= ntb
|
2018-03-30 15:28:25 +00:00
|
|
|
_ocs_fc= ocs_fc
|
2022-10-28 17:51:02 +00:00
|
|
|
_p2sb= p2sb
|
2022-07-19 08:15:34 +00:00
|
|
|
_qat= qat
|
2020-11-05 16:00:30 +00:00
|
|
|
_qatfw= qatfw
|
2022-08-04 13:37:55 +00:00
|
|
|
_qat_c2xxx= qat_c2xxx
|
|
|
|
|
_qat_c2xxxfw= qat_c2xxxfw
|
2004-01-16 15:55:29 +00:00
|
|
|
_safe= safe
|
|
|
|
|
_speaker= speaker
|
|
|
|
|
_splash= splash
|
2022-10-28 17:51:02 +00:00
|
|
|
_syscons= syscons
|
2012-03-06 18:44:52 +00:00
|
|
|
_wbwd= wbwd
|
2023-01-03 15:16:36 +00:00
|
|
|
_wdatwd= wdatwd
|
2017-01-28 02:22:15 +00:00
|
|
|
|
2004-01-16 15:55:29 +00:00
|
|
|
_aac= aac
|
2013-05-24 09:22:43 +00:00
|
|
|
_aacraid= aacraid
|
2004-01-16 15:55:29 +00:00
|
|
|
_acpi= acpi
|
2010-07-23 11:00:46 +00:00
|
|
|
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_aesni= aesni
|
|
|
|
|
.endif
|
2017-03-03 22:51:04 +00:00
|
|
|
_amd_ecc_inject=amd_ecc_inject
|
2009-11-30 11:44:03 +00:00
|
|
|
_amdsbwd= amdsbwd
|
2017-09-05 15:13:41 +00:00
|
|
|
_amdsmn= amdsmn
|
2009-03-13 16:08:08 +00:00
|
|
|
_amdtemp= amdtemp
|
2005-04-01 17:40:39 +00:00
|
|
|
_arcmsr= arcmsr
|
2007-11-07 20:08:15 +00:00
|
|
|
_asmc= asmc
|
Import Blake2 algorithms (blake2b, blake2s) from libb2
The upstream repository is on github BLAKE2/libb2. Files landed in
sys/contrib/libb2 are the unmodified upstream files, except for one
difference: secure_zero_memory's contents have been replaced with
explicit_bzero() only because the previous implementation broke powerpc
link. Preferential use of explicit_bzero() is in progress upstream, so
it is anticipated we will be able to drop this diff in the future.
sys/crypto/blake2 contains the source files needed to port libb2 to our
build system, a wrapped (limited) variant of the algorithm to match the API
of our auth_transform softcrypto abstraction, incorporation into the Open
Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX
accelerated OCF driver, blake2(4).
Optimized variants of blake2 are compiled for a number of x86 machines
(anything from SSE2 to AVX + XOP). On those machines, FPU context will need
to be explicitly saved before using blake2(4)-provided algorithms directly.
Use via cryptodev / OCF saves FPU state automatically, and use via the
auth_transform softcrypto abstraction does not use FPU.
The intent of the OCF driver is mostly to enable testing in userspace via
/dev/crypto. ATF tests are added with published KAT test vectors to
validate correctness.
Reviewed by: jhb, markj
Obtained from: github BLAKE2/libb2
Differential Revision: https://reviews.freebsd.org/D14662
2018-03-21 16:18:14 +00:00
|
|
|
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
|
|
|
|
|
_blake2= blake2
|
|
|
|
|
.endif
|
2016-11-24 20:08:17 +00:00
|
|
|
_bytgpio= bytgpio
|
2018-02-22 19:12:32 +00:00
|
|
|
_chvgpio= chvgpio
|
2004-01-16 15:55:29 +00:00
|
|
|
_ciss= ciss
|
add iic interface to ig4 driver, move isl and cyapa to iicbus
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
|
|
|
_chromebook_platform= chromebook_platform
|
2007-10-26 13:42:17 +00:00
|
|
|
_coretemp= coretemp
|
2019-11-21 11:22:08 +00:00
|
|
|
.if ${MK_SOURCELESS_HOST} != "no" && empty(KCSAN_ENABLED)
|
2011-12-28 23:26:58 +00:00
|
|
|
_hpt27xx= hpt27xx
|
2012-02-04 00:54:43 +00:00
|
|
|
.endif
|
2007-05-09 15:55:45 +00:00
|
|
|
_hptiop= hptiop
|
2019-11-21 11:22:08 +00:00
|
|
|
.if ${MK_SOURCELESS_HOST} != "no" && empty(KCSAN_ENABLED)
|
2004-10-24 08:53:40 +00:00
|
|
|
_hptmv= hptmv
|
2013-07-06 07:49:41 +00:00
|
|
|
_hptnr= hptnr
|
2007-12-15 00:56:17 +00:00
|
|
|
_hptrr= hptrr
|
2012-02-04 00:54:43 +00:00
|
|
|
.endif
|
2013-12-05 00:54:38 +00:00
|
|
|
_hyperv= hyperv
|
2004-05-13 11:13:55 +00:00
|
|
|
_ichwd= ichwd
|
2004-01-16 15:55:29 +00:00
|
|
|
_ida= ida
|
2016-12-27 22:37:24 +00:00
|
|
|
_intelspi= intelspi
|
2004-01-16 15:55:29 +00:00
|
|
|
_ips= ips
|
2012-01-31 19:38:18 +00:00
|
|
|
_isci= isci
|
2015-08-08 21:09:41 +00:00
|
|
|
_ipw= ipw
|
2006-03-17 13:06:19 +00:00
|
|
|
_iwi= iwi
|
2015-08-08 21:09:41 +00:00
|
|
|
_iwm= iwm
|
2008-04-29 21:36:17 +00:00
|
|
|
_iwn= iwn
|
2012-02-04 00:54:43 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
2015-08-08 21:09:41 +00:00
|
|
|
_ipwfw= ipwfw
|
|
|
|
|
_iwifw= iwifw
|
|
|
|
|
_iwmfw= iwmfw
|
2008-04-29 21:36:17 +00:00
|
|
|
_iwnfw= iwnfw
|
2012-02-04 00:54:43 +00:00
|
|
|
.endif
|
2006-06-26 23:41:07 +00:00
|
|
|
_nfe= nfe
|
2012-09-17 19:26:33 +00:00
|
|
|
_nvd= nvd
|
|
|
|
|
_nvme= nvme
|
2007-10-26 13:42:17 +00:00
|
|
|
_nvram= nvram
|
2006-03-17 18:54:44 +00:00
|
|
|
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
|
2005-08-18 00:30:22 +00:00
|
|
|
_padlock= padlock
|
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.
This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.
The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.
The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.
Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.
My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.
My Nomex pants are on. Let the feedback commence!
Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?)
Approved by: so(des)
2014-10-30 21:21:53 +00:00
|
|
|
_padlock_rng= padlock_rng
|
|
|
|
|
_rdrand_rng= rdrand_rng
|
2005-08-18 00:30:22 +00:00
|
|
|
.endif
|
2020-03-31 06:25:43 +00:00
|
|
|
_pchtherm = pchtherm
|
2004-01-16 15:55:29 +00:00
|
|
|
_s3= s3
|
2017-01-11 01:53:54 +00:00
|
|
|
_sdhci_acpi= sdhci_acpi
|
add superio driver
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.
I am planning to convert nctgpio and wbwd to superio bus very soon.
Also, I am working on itwd driver (watchdog in ITE SuperIO-s).
Additionally, there is ithwm driver based on the reverted sensors
import, but I am not sure how to integrate it given that we still lack
any sensors interface.
Discussed with: imp, jhb
MFC after: 7 weeks
Differential Revision: https://reviews.freebsd.org/D8175
2019-07-01 17:05:41 +00:00
|
|
|
_superio= superio
|
2014-10-05 07:27:05 +00:00
|
|
|
_tpm= tpm
|
2004-01-16 15:55:29 +00:00
|
|
|
_vesa= vesa
|
2014-10-05 07:27:05 +00:00
|
|
|
_viawd= viawd
|
2021-09-03 00:58:02 +00:00
|
|
|
_vmd= vmd
|
2014-10-05 07:27:05 +00:00
|
|
|
_wpi= wpi
|
|
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
|
|
|
|
_wpifw= wpifw
|
|
|
|
|
.endif
|
2009-09-21 23:58:29 +00:00
|
|
|
_x86bios= x86bios
|
2002-11-07 15:01:12 +00:00
|
|
|
.endif
|
2002-09-16 08:32:48 +00:00
|
|
|
|
2010-08-23 06:13:29 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "amd64"
|
2018-10-21 04:52:37 +00:00
|
|
|
_amdgpio= amdgpio
|
2018-01-19 04:34:06 +00:00
|
|
|
_ccp= ccp
|
2023-01-27 23:46:17 +00:00
|
|
|
_enic= enic
|
2018-10-12 22:40:54 +00:00
|
|
|
_iavf= iavf
|
2015-08-24 19:32:03 +00:00
|
|
|
_ioat= ioat
|
2014-08-28 17:40:19 +00:00
|
|
|
_ixl= ixl
|
2018-10-16 20:12:35 +00:00
|
|
|
_nvdimm= nvdimm
|
2015-07-17 20:30:30 +00:00
|
|
|
_pms= pms
|
2013-06-25 17:50:22 +00:00
|
|
|
_qlxge= qlxge
|
2011-11-03 21:20:22 +00:00
|
|
|
_qlxgb= qlxgb
|
2020-08-30 07:34:32 +00:00
|
|
|
_sume= sume
|
2017-08-19 01:12:05 +00:00
|
|
|
.if ${MK_SOURCELESS_UCODE} != "no"
|
2013-05-15 17:03:09 +00:00
|
|
|
_qlxgbe= qlxgbe
|
2017-04-04 06:16:59 +00:00
|
|
|
_qlnx= qlnx
|
2017-09-13 12:16:27 +00:00
|
|
|
.endif
|
2011-11-18 11:10:14 +00:00
|
|
|
_sfxge= sfxge
|
2017-08-16 10:38:06 +00:00
|
|
|
_sgx= sgx
|
|
|
|
|
_sgx_linux= sgx_linux
|
2018-04-26 16:59:06 +00:00
|
|
|
_smartpqi= smartpqi
|
2021-06-29 13:54:07 +00:00
|
|
|
_p2sb= p2sb
|
2015-01-26 06:44:48 +00:00
|
|
|
|
|
|
|
|
.if ${MK_BHYVE} != "no" || defined(ALL_MODULES)
|
2020-02-16 15:43:28 +00:00
|
|
|
.if ${KERN_OPTS:MSMP}
|
2011-05-13 04:54:01 +00:00
|
|
|
_vmm= vmm
|
2014-10-05 07:27:05 +00:00
|
|
|
.endif
|
2015-01-26 06:44:48 +00:00
|
|
|
.endif
|
2020-02-16 15:43:28 +00:00
|
|
|
.endif
|
2014-10-05 07:27:05 +00:00
|
|
|
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "i386"
|
|
|
|
|
# XXX some of these can move to the general case when de-i386'ed
|
|
|
|
|
# XXX some of these can move now, but are untested on other architectures.
|
|
|
|
|
_3dfx= 3dfx
|
|
|
|
|
_3dfx_linux= 3dfx_linux
|
|
|
|
|
_glxiic= glxiic
|
|
|
|
|
_glxsb= glxsb
|
|
|
|
|
_pcfclock= pcfclock
|
|
|
|
|
_pst= pst
|
|
|
|
|
_sbni= sbni
|
2004-01-28 04:15:10 +00:00
|
|
|
.endif
|
|
|
|
|
|
2020-07-30 14:45:05 +00:00
|
|
|
.if ${MACHINE_ARCH} == "armv7"
|
2011-12-30 03:48:39 +00:00
|
|
|
_cfi= cfi
|
2012-08-15 06:31:32 +00:00
|
|
|
_cpsw= cpsw
|
2011-12-30 03:48:39 +00:00
|
|
|
.endif
|
|
|
|
|
|
2010-07-13 12:47:31 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "powerpc"
|
2020-03-05 20:04:41 +00:00
|
|
|
_aacraid= aacraid
|
2010-10-31 18:27:05 +00:00
|
|
|
_agp= agp
|
2006-02-05 17:38:28 +00:00
|
|
|
_an= an
|
2012-02-01 03:42:14 +00:00
|
|
|
_cardbus= cardbus
|
|
|
|
|
_cbb= cbb
|
2011-12-30 03:48:39 +00:00
|
|
|
_cfi= cfi
|
2009-05-31 09:01:23 +00:00
|
|
|
_cpufreq= cpufreq
|
2012-02-05 13:29:01 +00:00
|
|
|
_exca= exca
|
2017-06-10 23:45:26 +00:00
|
|
|
_ffec= ffec
|
2018-06-07 11:25:36 +00:00
|
|
|
_nvd= nvd
|
|
|
|
|
_nvme= nvme
|
2013-07-13 07:16:45 +00:00
|
|
|
.endif
|
2003-01-09 16:37:37 +00:00
|
|
|
|
2020-09-22 23:49:30 +00:00
|
|
|
.if ${MACHINE_ARCH:Mpowerpc64*} != ""
|
2020-03-12 12:47:10 +00:00
|
|
|
_ixl= ixl
|
2019-09-14 03:30:34 +00:00
|
|
|
_nvram= opal_nvram
|
2010-07-17 13:34:01 +00:00
|
|
|
.endif
|
powerpc64*: port mlx5, OFED, KTLS and krping
Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.
krping requires a small change since it uses assembly for amd64 / i386.
NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.
Reviewers: #powerpc, hselasky
Subscribers: bdrewery, imp, emaste, jhibbits
Differential Revision: https://reviews.freebsd.org/D38786
2023-02-25 21:09:41 +00:00
|
|
|
|
2020-09-13 18:24:15 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "powerpc" && ${MACHINE_ARCH} != "powerpcspe"
|
Create a new MACHINE_ARCH for Freescale PowerPC e500v2
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
|
|
|
# Don't build powermac_nvram for powerpcspe, it's never supported.
|
2019-09-14 03:30:34 +00:00
|
|
|
_nvram+= powermac_nvram
|
Create a new MACHINE_ARCH for Freescale PowerPC e500v2
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
|
|
|
.endif
|
2010-07-17 13:34:01 +00:00
|
|
|
|
2022-10-28 19:45:30 +00:00
|
|
|
.if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "aarch64"
|
2018-01-22 07:10:30 +00:00
|
|
|
_bcm283x_clkman= bcm283x_clkman
|
2018-01-21 21:27:41 +00:00
|
|
|
_bcm283x_pwm= bcm283x_pwm
|
|
|
|
|
.endif
|
|
|
|
|
|
2020-10-14 12:28:48 +00:00
|
|
|
.if !(${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 110000)
|
|
|
|
|
# LLVM 10 crashes when building if_malo_pci.c, fixed in LLVM11:
|
|
|
|
|
# https://bugs.llvm.org/show_bug.cgi?id=44351
|
|
|
|
|
_malo= malo
|
|
|
|
|
.endif
|
|
|
|
|
|
2015-02-07 00:41:08 +00:00
|
|
|
SUBDIR+=${MODULES_EXTRA}
|
|
|
|
|
|
2005-01-20 05:43:24 +00:00
|
|
|
.for reject in ${WITHOUT_MODULES}
|
|
|
|
|
SUBDIR:= ${SUBDIR:N${reject}}
|
|
|
|
|
.endfor
|
|
|
|
|
|
2022-10-29 14:34:16 +00:00
|
|
|
.endif # MODULES_OVERRIDE -- Keep last
|
|
|
|
|
|
2001-09-21 11:21:06 +00:00
|
|
|
# Calling kldxref(8) for each module is expensive.
|
2003-01-21 05:52:48 +00:00
|
|
|
.if !defined(NO_XREF)
|
2003-03-12 14:32:46 +00:00
|
|
|
.MAKEFLAGS+= -DNO_XREF
|
2016-05-26 23:20:14 +00:00
|
|
|
afterinstall: .PHONY
|
2002-05-14 07:49:12 +00:00
|
|
|
@if type kldxref >/dev/null 2>&1; then \
|
2019-06-02 23:38:19 +00:00
|
|
|
${ECHO} ${KLDXREF_CMD} ${DESTDIR}${KMODDIR}; \
|
|
|
|
|
${KLDXREF_CMD} ${DESTDIR}${KMODDIR}; \
|
2002-05-14 07:49:12 +00:00
|
|
|
fi
|
2001-09-21 11:21:06 +00:00
|
|
|
.endif
|
|
|
|
|
|
2015-02-18 15:25:19 +00:00
|
|
|
SUBDIR:= ${SUBDIR:u:O}
|
|
|
|
|
|
1994-09-16 20:24:29 +00:00
|
|
|
.include <bsd.subdir.mk>
|
