fortunes, but occasionally remove them from the other 2 files when
they are not offensive, or not murphy'ish enough.
Where the version in fortunes had better attribution and/or formatting,
copy it over.
2. Fix a few typos
3. Use the full name of François De La Rochefoucauld, fix one of his
quotes, and remove the duplicate of it.
- Make atomic_init() work for GCC, as assigning to structs doesn't work.
- Fix misplaced parenthesis in atomic_is_lock_free() for GCC.
- Make atomic_compare_exchange_strong() for GCC return the proper
boolean value, whether object == expected.
- Fix argument passing in atomic_exchange_explicit() for GCC.
This library implements the C11 threads interface on top of the pthreads
library. As discussed on the lists, the preferred way to implement
this, is as a separate library.
It is unlikely that these functions will be used a lot in the future. It
would have been easier if the C11 working group standardized (a subset
of) pthreads and clock_nanosleep(). Having it as a separate library
allows the embedded people to omit it from their system.
Discussed on: arch@, threads@
doing split software/hardware LED configuration, we can now simply
treat "softled" as an "output" mux type.
This works fine on this DWA-552. Previous generation (pre-11n NICs) don't
have a GPIO mux - only input/output configuration - so they ignore this
field.
The hardware (MAC) LED blinking involves a few things:
* Selecting which GPIO pins map to the MAC "power" and "network" lines;
* Configuring the MAC LED state (associated, scanning, idle);
* Configuring the MAC LED blinking type and speed.
The AR5416 HAL configures the normal blinking setup - ie, blink rate based
on TX/RX throughput. The default AR5212 HAL doesn't program in any
specific blinking type, but the default of 0 is the same.
This code introduces a few things:
* The hardware led override is configured via sysctl 'hardled';
* The MAC network and power LED GPIO lines can be set, or left at -1
if needed. This is intended to allow only one of the hardware MUX
entries to be configured (eg for PCIe cards which only have one LED
exposed.)
TODO:
* For AR2417, the software LED blinking involves software blinking the
Network LED. For the AR5416 and later, this can just be configured
as a GPIO output line. I'll chase that up with a subsequent commit.
* Add another software LED blink for "Link", separate from "activity",
which blinks based on the association state. This would make my
D-Link DWA-552 have consistent and useful LED behaviour (as they're
marked "Link" and "Activity."
* Don't expose the hardware LED override unless it's an AR5416 or later,
as the previous generation hardware doesn't have this multiplexing
setup.
Some of the NICs I have here power up with the LEDs blinking, which is
incorrect. The blinking should only occur when the NIC is attempting
to associate.
* On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC
LED but leaves the "Network" MAC LED the way it is.
* On resume, also init it to HAL_LED_INIT unless in station mode, where
it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will
call newstate() at some point, which will refiddle the LEDs.
I've tested this on a handful of 11n and pre-11n NICs. The blinking
behaviour is slightly more sensible now.
relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
Even though these header files make little sense to me, they are part of
the standard. By including these header files, you can simply use
`alignas', `alignof' and `noreturn' instead of the underscore-prefixed
versions.
kernel builds. All the instances of this warning in our tree are
completely harmless, and many people seem to like adding extra
parentheses to make precedence clearer.
MFC after: 1 week
tested) with clang and gcc, and more efficiently with clang+a big out-of-tree
diff that I need to commit soon (once it's been tidied and reviewed a bit).
Large portions by: ed
Reviewed by: ed
Approved by: dim (mentor)
builds. All the instances of this warning in our tree are completely
harmless. (Most of the empty bodies look to be used simply as reminder
for the developer to add something later.)
While here, assign to CWARNEXTRA with ?=, so it can be overridden
easily, if needed.
MFC after: 1 week
to always evaluate to 0 if we are using a compiler that doesn't implement them.
This lets us use the macros easily in standard headers (e.g. stdatomic.h, which
should be the subject of my next commit).
Approved by: dim (mentor)
sysclock_getsnapshot() function allows the caller to obtain a snapshot of all
the system clock and timecounter state required to create time stamps at a later
point. The sysclock_snap2bintime() function converts a previously obtained
snapshot into a bintime time stamp according to the specified flags e.g. which
system clock, uptime vs absolute time, etc.
These KPIs enable useful functionality, including direct comparison of the
feedback and feed-forward system clocks and generation of multiple time stamps
with different formats from a single timecounter read.
Committed on behalf of Julien Ridoux and Darryl Veitch from the University of
Melbourne, Australia, as part of the FreeBSD Foundation funded "Feed-Forward
Clock Synchronization Algorithms" project.
For more information, see http://www.synclab.org/radclock/
In collaboration with: Julien Ridoux (jridoux at unimelb edu au)
