| Age | Commit message (Collapse) | Author |
|---|
|
the big change is removing the integration with and reliance on
bridge(4) for learning vxlan endpoints. we have the etherbridge
layer now (which is used by veb, nvgre, bpe, etc) so vxlan can
operate independently of bridge(4) (or any other driver) while still
dynamically learning about other endpoints.
vxlan now uses the udp socket upcall mechanism to receive packets.
this means it actually creates and binds udp sockets to use rather
adding code in the udp layer for stealing packets from the udp
layer.
i think it's also important to note that this adds loop prevention
to the code. this stops a vxlan interface being used to transmit a
packet that was encapsulated in itself.
i want to clear this out of my tree where it's been sitting for
nearly a year. noone seems too concerned with the change either
way.
ok claudio@
|
|
This splits out the MI sequencing, backing it with per-architecture helper
functions. Further steps will be neccesary because ACPI and MD are too
tightly coupled, but soon we'll be able to use this code for more architectures
(which depends on figuring out the lowest-level cpu sleeping method)
ok kettenis
|
|
OK deraadt@ phessler@
|
|
|
|
API implemented is a deadend.
OK akoshibe@ yasuoka@ deraadt@ kn@ patrick@ sthen@
|
|
|
|
this allows us to dynamically trace function boundaries with btrace by patching
prologues and epilogues with a breakpoint upon which the handler records the data,
sends it back to userland for btrace to consume.
currently it's hidden behind DDBPROF, and there is still a lot to cleanup and
improve, but basic scripts that observe return codes from a probed function
work.
from Tom Rollet, with various changes by me
feedback and ok mpi@
|
|
ok deraadt@ kettenis@
|
|
Keeping files in CVS HEAD for now until we are certain we're not going back.
ok deraadt@
|
|
Otherwise compiling a kernel witout any other wifi drivers fails.
OK patrick deraadt
|
|
OK deraadt@ mpi@
|
|
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.
|
|
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@
|
|
the "ports" that nvgre provides to etherbridge are ip addresses
used in the underlay network.
ok patrick@ jmatthew@
|
|
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@
|
|
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@
|
|
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@
|
|
OK deraadt@
|
|
in preparation for upcoming ACPI-attachment.
ok kettenis@
|
|
this fell out of a discussion with mortimer
ok kettenis
|
|
it's like ksyms, but different
|
|
|
|
|
|
|
|
noticed by tobhe@
diff from kettenis@ (who forgot to commit this bit)
|
|
RK3399 SoC.
ok patrick@
|
|
ok tedu@ krw@ deraadt@
|
|
ok jsg
|
|
ok tedu@ jsg@
|
|
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@
|
|
This driver was never completed. It only mapped memory and established
an interrupt.
ok krw@ mlarkin@ dlg@
|
|
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@
|
|
ok mlarkin@
|
|
ok kettenis@, semarie@, deraadt@
|
|
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.
|
|
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@
|
|
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@
|
|
|
|
|
|
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@
|
|
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@
|
|
mpe doesnt need ether as a depend while im here.
|
|
ok claudio@
|
|
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@
|
|
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.
|
|
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@
|
|
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@
|
|
OK mpi@
|
|
ok mlarkin@, patrick@
|
|
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@
|
