introduced in the prior patch.
The queue has capacity to store 8 link state changes, if it overflows then
the oldest state change is lost, but the oldest DOWN state change is
preserved to ensure any subsequent UP state changes reflect properly.
Because there are only 3 states to queue, the queue itself is implemented
by storing 2-bit numbers in a bigger one.
To increase the size of the queue, just increase the size of the backing
store to a bigger number.
- Include <ufs/lfs/lfs.h> for union lfs_dinode &c.
- Include <string.h> or <sys/systm.h> for memcpy.
- Avoid signedness mismatch in lfs dino accessor for `rdev'.
- Avoid shadowing global `index'.
by default, because it is afraid that the stricter tests
will break userland code. The new binutils is pickier about
this. Gcc 5.x fixes the issue so for now, set explicitly
the assembler soft-float flags when we build the kernel.
see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64569
Like .sinclude missing file will be ignored.
Like .depend stale dependencies will be ignored.
Allows better implementation of auto depend.
Reviewed by: christos
Requested by: Bryan Drewery at FreeBSD.
Some systems seem to have gotten stuck in a softint processing loop
doing nothing and then trying to do it again. Might fix gson's
frozen qemu/anita sparc autobuilds -- tested on macallan's real sparc
hardware and confirmed to fix at least some freeze at boot.
There are three cases to consider here:
1. You have on-demand synchronous rndsources, e.g. RDRAND (and you're
willing to use it). In that case, you'll just use those whenever you
need to extract entropy. There's no benefit to requesting more from
them when we're entering data into the pool.
2. You have on-demand asynchronous rndsources. These should continue
trying to feed data to the entropy pool as long as it needs more, so
there's no benefit to requesting more from them when we're entering
data into the pool.
3. You don't have any on-demand rndsources. Then rnd_getmore does
nothing, so there's no benefit to calling it.
ok tls
Avoids lock recursion in rndsinks:
rndsink user holds lock
calls rndsink_request
calls rnd_getmore
calls an rndsource callback
calls rnd_add_data
calls rnd_process_events
calls rndsinks_distribute
calls rndsink callback
acquires rndsink user lock.
This can happen only before the rnd_process_events softint is
established, but that's enough to cause a problem and is the main
reason why all our HWRNG drivers are so byzantine (soon to be
fixed!).
ok tls
