summaryrefslogtreecommitdiffstats
path: root/sys/conf/files (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Make ddb's dependency on libz explicit.visa2021-03-311-12/+12
| | | | OK deraadt@ mpi@
* Add RA, a new 11n Tx rate adaptation module for net80211.stsp2021-03-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Written by Christian Ehrhardt and myself, based on ieee80211_mira.c but with significant changes. The main difference is that RA does not attempt to precisely measure actual throughput but simply deducts a loss percentage from the theoretical throughput which can be achieved by a given MCS. Unlike MiRa, RA does not use timeouts to trigger probing. Probing is triggered only by changes in measured throughput. Unlike MiRA, RA doesn't care whether a frame was part of an A-MPDU. RA simply collects statistics for individual subframes. This makes reporting very easy for drivers and seems to work well enough in practice. Another difference is that drivers can report multi-rate retries properly via ieee80211_ra_add_stats_ht(mcs, total, fail) which can be called several times before ieee80211_ra_choose() selects a new Tx rate. There is no reason any issues could not be fixed in ieee8011_mira.c but I felt it was a good moment to burn the house down and start over. And since this code diverges from how MiRA is described in the research paper applying the "MiRA" label becomes inappropriate.
* add veb(4), a Virtual Ethernet Bridge driver.dlg2021-02-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | my intention is to replace bridge(4), but the way it works is different enough from from bridge that a name change is justified to distinguish them. it also makes it easier to commit it to the tree and work on it in parallel to bridge, and allows a window of migration. the main difference between veb(4) and bridge(4) is how they use interfaces as ports. veb takes over interfaces completely and only uses them to receive and transmit ethernet packets. bridge also use each interface as a port to the ethernet segment it's connected to, but also tries to continue supporting the use of the interface as a way to talk to the network stack on the local system. supporting the use of interfaces for both external and local communication is where most of my confusion with bridge comes from, both when i'm trying to operate it and also understand the code. changing this semantic is where most of the simplification in veb comes from compared to bridge. because veb takes over interfaces, the ethernet network set up on a veb is isolated from the host network stack. by default veb does not interact with pf or the ip (and mpls) stacks. to enable pf for ip frames going over veb ports link1 on the veb interface must be set. to have the stack interact with a veb network, vport interfaces must be created and added as ports to a veb. the vport interface driver is provided as part of veb, and is handled specially by veb. veb usually prevents the use of ports by the stack for sending an receiving packets, but that's why vports exist, so veb has special handling for them. veb already supports a lot of the other features that bridge has, including bridge rules and protected domains, but i got tired of working out of the tree and stopped implementing them. the main outstanding features is better address table management, the blocknonip flag on ports, transparent ipsec interception, and spanning tree. i may not bother with spanning tree unless someone tells me that they actually use it. the core ethernet learning bridge functionality is provided by the etherbridge code that was factored out of nvgre and bpe. veb is already (a lot) faster than bridge, and is better prepared to operate in parallel on multiple CPUs concurrently. thanks to hrvoje popovski for testing some earlier versions of this. discussed with many ok patrick@ jmatthew@
* cut nvgre(4) over to use common etherbridge code.dlg2021-02-211-2/+2
| | | | | | | the "ports" that nvgre provides to etherbridge are ip addresses used in the underlay network. ok patrick@ jmatthew@
* cut bpe(4) over to using the common etherbridge code.dlg2021-02-211-2/+2
| | | | | | | | | it's pretty straightforward since etherbridge was mostly based on this code in the first place. the etherbridge_ops that bpe provides to etherbridge set entries up to point at mac addresses in the underlay network. ok patrick@ jmatthew@
* add etherbridge, the guts of a learning bridge that can be reused.dlg2021-02-211-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | this allows for the factoring out of the learning bridge code i wrote in bpe and nvme, and should be reusable for other drivers needing a mac learning bridge. the core data structures are an etherbridge struct to represent the learning bridge, eb_entry structs for each mac address entry that the bridge knows about, and an etherbridge_ops struct that drivers fill in so that they can use this code. eb_entry structs are stored in a hash table made up of SMR_TAILQs to support lookups of entries quickly and concurrently in the forwarding path. they are also stored in a locked red-black tree to help manage the uniqueness of the mac address in the table. the etherbridge_ops handlers mostly deal with comparing and testing the "ports" associated with mac address table entries. the "port" that a mac address entry is associated with is opaque to the etherbridge code, which allows for this code to be used by nvgre and bpe which map mac addresses inside the bridge to addresses in their underlay networks. it also supports traditional bridges where "ports" are actual interfaces. ok patrick@ jmatthew@
* Add a RAID1C (raid1 + crypto) softraid(8) discipline.stsp2021-02-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts multiple chunks during creation and assembly like the RAID1 discipline. To deal with failing disks a RAID1C volume may be assembled with a smaller number of chunks than the volume was created with. The volume will then come up in degraded state. If the volume is now detached and assembled again with the correct number of chunks, any re-added chunks will require a rebuild. Consequently, assembling RAID1C volumes requires careful attention to the chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the command line during volume assembly, then this chunk will need to be rebuilt. At least one known-good chunk is required in order to assemble the volume. Like CRYPTO, RAID1C supports passphrase and key-disk authentication. Key-disk based volumes are assembled automatically if the key disk is present while the system is booting up. Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet. RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines. At present RAID1C's discipline-specific data structure is shared with that of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom RAID1C data structure would require CRYPTO code to access struct sr_crypto via a pointer instead of via a member field of struct sr_discipline. ok jsing@
* Drop tcp_trace() from SMALL_KERNEL builds to make room on amd64 floppyvisa2021-01-281-2/+2
| | | | OK deraadt@
* Split imxiic(4) into the FDT-attachment code and the i.MX I2C codepatrick2020-11-171-1/+5
| | | | | | in preparation for upcoming ACPI-attachment. ok kettenis@
* __main() is no longer used by any of our toolchainsderaadt2020-07-201-2/+1
| | | | | this fell out of a discussion with mortimer ok kettenis
* tell the kernel how to build kstatdlg2020-07-061-1/+4
| | | | it's like ksyms, but different
* tell config how to build wg(4)dlg2020-06-211-1/+7
|
* wire intrmap into the builddlg2020-06-171-1/+3
|
* wire stoeplitz code into the tree.dlg2020-06-161-1/+3
|
* Add bse(4) device to unbreak build.patrick2020-04-151-1/+5
| | | | | noticed by tobhe@ diff from kettenis@ (who forgot to commit this bit)
* Add rkdwhdmi(4), a driver for the HDMI transmitter found on the Rockchipkettenis2020-03-021-1/+6
| | | | | | RK3399 SoC. ok patrick@
* cleanup unused headers generated by configjsg2020-01-241-7/+7
| | | | ok tedu@ krw@ deraadt@
* remove unreferenced ncr5380 driver filestedu2020-01-241-3/+1
| | | | ok jsg
* Nuke references to zaurus zombies.krw2020-01-241-2/+1
| | | | ok tedu@ jsg@
* Import dt(4) a driver and framework for Dynamic Profiling.mpi2020-01-211-1/+7
| | | | | | | | | | | The design is fairly simple: events, in the form of descriptors on a ring, are being produced in any kernel context and being consumed by a userland process reading /dev/dt. Code and hooks are all guarded under '#if NDT > 0' so this commit shouldn't introduce any change as long as dt(4) is disable in GENERIC. ok kettenis@, visa@, jasper@, deraadt@
* remove sli(4)jsg2020-01-111-5/+1
| | | | | | | This driver was never completed. It only mapped memory and established an interrupt. ok krw@ mlarkin@ dlg@
* remove dpt(4) driver for DPT EATA SCSI RAIDjsg2020-01-101-5/+1
| | | | | | | Not built since 2006, and a mail from 2004 mentions no one having hardware. Unsurprisingly it does not build with clang. ok mlarkin@ krw@ deraadt@
* Move uvmexp_print() to a better place.mpi2019-12-051-2/+1
| | | | ok mlarkin@
* Kill uvm_deallocate(9) and use uvm_unmap() directly.mpi2019-11-051-2/+1
| | | | ok kettenis@, semarie@, deraadt@
* remove mobileip(4)dlg2019-11-041-3/+1
| | | | | | | noone seems to use it, and we should not encourage people to use it by having it available. it's been disabled for most of the last release and noones asked for it in 6.6, so i'm taking that as an ok for this removal.
* src/sys/netinet/ip_ether.c is empty, and gif doesn't need it.dlg2019-10-051-2/+1
| | | | | | | | gif may have needed it when you could switch modes with gif, but now that's handled by if_etherip.c. ip_ether.c is empty, so we can plan to remove it. ok visa@ jca@ deraadt@
* Replace dwge(4) with a new driver based on dwxe(4). There are manykettenis2019-09-291-6/+1
| | | | | | | | | | similarities between the two and using a common approach helps fixing bugs. The new driver is better integrated with the device tree framework and is faster (mainly because the DMA engine is configured properly now). Tested on all currently supported variants of the hardware. ok jsg@, jmatthew@
* wire up tpmr(4), an 802.1Q Two-Port MAC Relay implementationdlg2019-08-011-1/+3
|
* wire up aggrdlg2019-07-051-1/+3
|
* Improve the interaction between efifb(4), inteldrm(4) and radeondrm(4)kettenis2019-05-041-2/+2
| | | | | | | | | | | | | | | | when we have a serial console by introducing the notion of a "primary" graphics device. The primary graphics device is the one set up and used by firmware (BIOS, UEFI). The goal is to make sure that wsdisplay0 and drm0 reliably attach to the primary graphics device such that X works out of the box even if you have multiple cards or if you are using a serial console. This also fixes the situation where inteldrm(4) or radeondrm(4) would take over the console on UEFI systems even if the kernel was booted with a serial console. ok jsg@
* Add kubsan(4), a undefined behavior sanitizer for the kernel. It'santon2019-03-181-1/+2
| | | | | | | | | | | | | capable of detecting undefined behavior at runtime and all findings are printed to the system console, including the offending line in the source code. kubsan is limited to architectures using Clang as their default compiler and is not enabled by default. Derived from the NetBSD implementation. ok kettenis@ visa@
* list mpls as a depend for mpe and mpw, dont require bridge to build mpwdlg2019-02-281-4/+4
| | | | mpe doesnt need ether as a depend while im here.
* add mpip(4)dlg2019-02-281-1/+4
| | | | ok claudio@
* Introduce safe memory reclamation, a mechanism for reclaiming sharedvisa2019-02-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | objects that readers can access without locking. This provides a basis for read-copy-update operations. Readers access SMR-protected shared objects inside SMR read-side critical section where sleeping is not allowed. To reclaim an SMR-protected object, the writer has to ensure mutual exclusion of other writers, remove the object's shared reference and wait until read-side references cannot exist any longer. As an alternative to waiting, the writer can schedule a callback that gets invoked when reclamation is safe. The mechanism relies on CPU quiescent states to determine when an SMR-protected object is ready for reclamation. The <sys/smr.h> header additionally provides an implementation of singly- and doubly-linked lists that can be used together with SMR. These lists allow lockless read access with a concurrent writer. Discussed with many OK mpi@ sashan@
* add bpe(4) or Backbone Provider Edge interfacesdlg2018-12-201-1/+3
| | | | | | | | Backbone refers to 802.1ah or 802.1Q Provider Backbone Bridges (PBB), or mac-in-mac, which is like vlans except it completely encapsulates the inner packet rather than just add a shim to it. This removes the need for Backbone Core Bridges (ie, switches between bpe instances) to know all the addresses on all the networks.
* Rework kcov kernel config. Instead of treating kcov as both an option and aanton2018-08-211-1/+4
| | | | | | | | | | | | pseudo-device, get rid of the option. Enabling kcov now requires the following line to be added to the kernel config: pseudo-device kcov 1 This is how pseudo devices are enabled in general. A side-effect of this change is that dev/kcov.c will no longer be compiled by default. Prodded by deraadt@; ok mpi@ visa@
* Unveiling unveil(2).beck2018-07-131-1/+2
| | | | | | | | | | | | | This brings unveil into the tree, disabled by default - Currently this will return EPERM on all attempts to use it until we are fully certain it is ready for people to start using, but this now allows for others to do more tweaking and experimentation. Still needs to send the unveil's across forks and execs before fully enabling. Many thanks to robert@ and deraadt@ for extensive testing. ok deraadt@
* Remove raw_usrreq and raw_cb, nothing is using them anymore.claudio2018-07-101-2/+1
| | | | OK mpi@
* Allow pluart(4) to attach to acpi(4).kettenis2018-07-021-1/+5
| | | | ok mlarkin@, patrick@
* add a small driver for AMDs cryptographic co processor.dlg2018-04-201-1/+5
| | | | | | | | | | the hardware provides crypto offload, zlib offload, and an rng. this code only supports the rng at the moment. this device is present on their amd seatlle platforms, and very present on their epyc stuff. ok kettenis@ jmatthew@
* prune files.* entries that refer to files not in treejsg2018-02-141-3/+1
| | | | ok krw@ mpi@
* kern_mutex.c is gone.mpi2018-02-141-2/+1
|
* split mobileip(4) out from the gre(4) driver.dlg2018-02-071-1/+3
| | | | | | | | having mobileip in gre makes it hard to cut gre up. the current mobileip code is also broken, so this is def and improvement. it also makes it easy to disable and remove mobileip in the future. ok claudio@ henning@
* syncookies for pf.henning2018-02-061-1/+2
| | | | | | | | | | | | | | | | | when syncookies are on, pf will blindly answer each and every SYN with a syncookie-SYNACK. Upon reception of the ACK completing the 3WHS, pf will reconstruct the original SYN, shove it through pf_test, where state will be created if the ruleset permits it. Then massage the freshly created state (we won't see the SYNACK), set up the sequence number modulator, and call into the existing synproxy code to start the 3WHS with the backend host. Add an - somewhat basic for now - adaptive mode where syncookies get enabled if a certain percentage of the state table is filled up with half-open tcp connections. This makes pf firewalls resilient against large synflood attacks. syncookies are off by default until we gained more experience, considered experimental for now. see http://bulabula.org/papers/2017/bsdcan/ for more details. joint work with sashan@, widely discussed and with lots of input by many
* Add PCI attachment for dwiic(4) needed by Intel 100 Series machinesjcs2017-11-161-1/+5
| | | | ok kettenis
* remove MALLOC_DEBUGdlg2017-11-141-2/+1
| | | | | | | | the code has rotted, and obviously hasnt been used for ages. it is also hard to make mpsafe. if we need something like this again it would be better to do it from scratch. ok tedu@ visa@
* Inline trivial functions from raw_cb.c and tedu it.florian2017-11-031-2/+1
| | | | Suggested by and OK mpi, OK visa
* Add bwfm(4), a driver for Broadcom FullMAC WiFi controllers. Thepatrick2017-10-111-1/+5
| | | | | | | | | | | | | | FullMAC, in comparison to SoftMAC, does most WiFi handling in the firmware that's running on the controller. This means we have to work around the net80211 stack while still implementing all the WiFi interfaces to userland. This driver is still in early development. So far it can connect to open WiFis over the USB bus. SDIO and PCIe support, for devices like the Raspberry Pi 3 or the Macbooks, is not yet implemented. Also mbufs on the transmit path leak and are not yet freed. ok stsp@
* Remove option DDB_STRUCTINFO. Now that ddb(4) is CTF aware, similarmpi2017-09-121-2/+1
| | | | | | functionnalities are available in GENERIC. ok jasper@, deraadt@, guenther@, dlg@
* Merge DDBCTF into DDB.mpi2017-08-111-2/+2
|
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.