code in sys/kern/kern_dump.c. Most dumpsys() implementations are nearly
identical and simply redefine a number of constants and helper subroutines;
a generic implementation will make it easier to implement features around
kernel core dumps. This change does not alter any minidump code and should
have no functional impact.
PR: 193873
Differential Revision: https://reviews.freebsd.org/D904
Submitted by: Conrad Meyer <conrad.meyer@isilon.com>
Reviewed by: jhibbits (earlier version)
Sponsored by: EMC / Isilon Storage Division
get the tail part of the path. We can now build kernels the
old-fashioned way on FreeBSD 9.x and 10.x on at least amd64 using
clang 3.3, 3.4 or gcc 4.2.1 (though with the latter you need
WITHOUT_MODULES="aesni vmm cxgbe" due to various issues with
gcc 4.2.1).
of the scan API.
The eventual aim is to have 'ieee80211_scan.c' have the net80211 and
driver facing scan API to start, finish and continue doing scanning
while 'ieee80211_swscan.c' implements the software scanner that
runs the scan task, handles probe request/reply bits, configures
the VAP off-channel, changes channel and does the scanning bits.
For NICs that do no scanning at all, the existing code is needed.
ath(4) and most of the other NICs (dumb USB ones in particular)
do little to no scan offload - it's all done in software.
Some NICs may do single channel at a time scanning; I haven't really
checked them out in detail.
iwn(4), the upcoming 7260 driver stuff, the new Qualcomm Atheros
11ac chipsets and the Atheros mobile/USB full-offload chips all
have complete scan engines in firmware. We don't have to drive
any of it at all - the firmware just needs to be told what to scan,
when to scan, how long to scan. It'll take care of going off
channel, pausing TX/RX appropriately, sending sleep notification
to the AP, sending probe requests and handling probe responses.
It'll do passive/active scan itself. It's almost completely
transparent to the network stack - all we see are scan notifications
when it finishes scanning each channel and beacons/probe responses
when it does its thing. Once it's done we get a final notification
that the scan is complete, with some scan results in the message.
The iwn(4) NICs handle doing active scanning too as an option
and will handle waiting appropriately on 5GHz passive channels
before active scanning.
There's some more refactoring, tidying up and lock assertions to
sprinkle around to tidy this whole thing up before I turn swscan.c
into another set of ic methods to override by the driver or
alternate scan module. So in theory this is all one big no-op
commit. In theory.
Tested:
* iwn(4) 5200, STA mode
* ath(4) 6205, STA mode
* ath(4) - various NICs, AP mode
has support for the .codeXX directives). However, it is desirable, for
a time, to allow kernels to be built with clang 3.4. Historically, it
has been advantageous to allow stable X-1 to build kernels the old
way (so long as the impact of doing so is small), and this restores
that ability.
Also, centralize the addition of ${ASM_CFLAGS.${.IMPSRC}}, place it in
kern.mk rather than kern.pre.mk so that all modules can benefit, and
give the same treatment to CFLAGS in kern.mk as well.
building with gcc 4.2
This has been requested several times over the past few months by several
people (including me), because gcc 4.2 just gets it wrong too often. It's
causing us to litter the code with lots of bogus initializers just to
squelch the warnings. We still have clang and coverity telling us about
uninitialized variables, and they do so more accurately.
mostly paves the way for the new pmap code, and shouldn't result in any
noticible behavior differences.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>,
Michal Meloun <meloun@miracle.cz
CWARNFALGS.$file centrally so we don't have to have it in all the
places. Remove a few warning flags that are no longer needed.
Also, always use -Wno-unknown-pragma to (hopefully temporarily) work
around #pragma ident in debug.h in the opensolaris code. Remove some
stale warning suppression that's no longer necessary.
roughly 10 years, and the driver has not enjoyed any significant maintenance
since long before that. Despite well-meaning efforts from a number of
people, myself included, it never made the jump to 64-bit and was relegated
to the back-corners of i386. Now its frailty is hampering forward progress
with Clang. Any renewed engineering efforts are of course welcome and can
happen outside of the tree. No MFC of this is planned.
When we started compiling the kernel with -march=armv7 the compiler
started emitting new types of relocation info which are incompatible with
the shared-lib file format used by .ko modules. This workaround prevents
the compiler from emitting the instruction sequences that require the
new relocs. This amounts to using an undocumented internal compiler
flag, so this is just a temporary workaround while we look for a good fix.
PR: 196407
the place where the C dialect is selected. Have a fairly long list
of newly requires warning suppression for clang 3.5.0, also
centralized in kern.mk. Survive the fallout of the removal of
bsd.sys.mk from bsd.kmod.mk.
raft of new warnings that appear to be on by default in clang 3.5.0.
Fix RPI-B build issues with new clang not liking the ability to pass
arbitrary flags to as, since some flags are more arbitrary (and thus
verboten) than others.
These warnings should be actually fixed in the code, but this is a
band-aide to get things (almost) building again.
a) Front load as much work as possible in if_transmit, before any driver
lock or software queue has to get involved.
b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This
is specifically for the tx multiqueue model where one of the if_transmit
producer threads becomes the consumer and other producers carry on as
usual. mp_ring is implemented as standalone code and it should be
possible to use it in any driver with tx multiqueue. It also has:
- the ability to enqueue/dequeue multiple items. This might become
significant if packet batching is ever implemented.
- an abdication mechanism to allow a thread to give up writing tx
descriptors and have another if_transmit thread take over. A thread
that's writing tx descriptors can end up doing so for an unbounded
time period if a) there are other if_transmit threads continuously
feeding the sofware queue, and b) the chip keeps up with whatever the
thread is throwing at it.
- accurate statistics about interesting events even when the stats come
at the expense of additional branches/conditional code.
The NIC txq lock is uncontested on the fast path at this point. I've
left it there for synchronization with the control events (interface
up/down, modload/unload).
c) Add support for "type 1" coalescing work request in the normal NIC tx
path. This work request is optimized for frames with a single item in
the DMA gather list. These are very common when forwarding packets.
Note that netmap tx in cxgbe already uses these "type 1" work requests.
d) Do not request automatic cidx updates every 32 descriptors. Instead,
request updates via bits in individual work requests (still every 32
descriptors approximately). Also, request an automatic final update
when the queue idles after activity. This means NIC tx reclaim is still
performed lazily but it will catch up quickly as soon as the queue
idles. This seems to be the best middle ground and I'll probably do
something similar for netmap tx as well.
e) Implement a faster tx path for WRQs (used by TOE tx and control
queues, _not_ by the normal NIC tx). Allow work requests to be written
directly to the hardware descriptor ring if room is available. I will
convert t4_tom and iw_cxgbe modules to this faster style gradually.
MFC after: 2 months
code alongside the existing implementation and quickly toggle between
the two implementations when testing. Once the new code is past its
teething stage we can remove this option.
initially set up the MMU. Some day they may also be useful as part of
suspend/resume handling, when we get better at power management.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>,
Michal Meloun <meloun@miracle.cz
mechanism defined for armv7 (and also present on some armv6 chips including
the arm1176 used on rpi). The information is parsed into a global cpuinfo
structure, which will be used by (upcoming) new cache and tlb maintenance
code to handle cpu-specific variations of the maintence sequences.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>,
Michal Meloun <meloun@miracle.cz
images into the kernel as currently included into iwn6000g2{a,b}fw.ko
and delete the old files, missed in r254199 and r259135 respectively.
MFC after: 3 days
which means that the NFSCLIENT and NFSSERVER
kernel options will no longer work. This commit
only removes the kernel components. Removal of
unused code in the user utilities will be done
later. This commit does not include an addition
to UPDATING, but that will be committed in a
few minutes.
Discussed on: freebsd-fs
the orphaned descendants. Base of the API is modelled after the same
feature from the DragonFlyBSD.
Requested by: bapt
Reviewed by: jilles (previous version)
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
for counter mode), and AES-GCM. Both of these modes have been added to
the aesni module.
Included is a set of tests to validate that the software and aesni
module calculate the correct values. These use the NIST KAT test
vectors. To run the test, you will need to install a soon to be
committed port, nist-kat that will install the vectors. Using a port
is necessary as the test vectors are around 25MB.
All the man pages were updated. I have added a new man page, crypto.7,
which includes a description of how to use each mode. All the new modes
and some other AES modes are present. It would be good for someone
else to go through and document the other modes.
A new ioctl was added to support AEAD modes which AES-GCM is one of them.
Without this ioctl, it is not possible to test AEAD modes from userland.
Add a timing safe bcmp for use to compare MACs. Previously we were using
bcmp which could leak timing info and result in the ability to forge
messages.
Add a minor optimization to the aesni module so that single segment
mbufs don't get copied and instead are updated in place. The aesni
module needs to be updated to support blocked IO so segmented mbufs
don't have to be copied.
We require that the IV be specified for all calls for both GCM and ICM.
This is to ensure proper use of these functions.
Obtained from: p4: //depot/projects/opencrypto
Relnotes: yes
Sponsored by: FreeBSD Foundation
Sponsored by: NetGate
Mave the grant table code into the dev/xen folder in preparation for turning
it into a device using the newbus interface. This is just code motion, no
functional changes.
Sponsored by: Citrix Systems R&D
When running as a Xen PVH Dom0 we need to add custom buses that override
some of the functionality present in the ACPI PCI Bus and the PCI Bus. We
currently override the ACPI PCI Bus, but not the PCI Bus, so add a new
override for the PCI Bus and share the generic functions between them.
Reported by: David P. Discher <dpd@dpdtech.com>
Sponsored by: Citrix Systems R&D
conf/files.amd64:
- Add the new files.
x86/xen/xen_pci_bus.c:
- Generic file that contains the PCI overrides so they can be used by the
several PCI specific buses.
xen/xen_pci.h:
- Prototypes for the generic overried functions.
dev/xen/pci/xen_pci.c:
- Xen specific override for the PCI bus.
dev/xen/pci/xen_acpi_pci.c:
- Xen specific override for the ACPI PCI bus.
to automatically set the armv6 option when MACHINE_ARCH is armv6. That
allows replacing ever-growing lists of cpu names as options to compile
a given file with the using either "optional armv6" or "optional !armv6".
