with other profiling and debugging options, such as INVARIANTS, WITNESS,
kernel profiling, etc. They all interfere with each other nastily and
will generate fairly useless results.
callout is first initialised, using a new function callout_init_mtx().
The callout system will acquire this mutex before calling the callout
function and release it on return.
In addition, the callout system uses the mutex to avoid most of the
complications and race conditions inherent in asynchronous timer
facilities, so mutex-protected callouts have much simpler semantics.
As long as the mutex is held when invoking callout_stop() or
callout_reset(), then these functions will guarantee that the callout
will be stopped, even if softclock() had already begun to process
the callout.
Existing Giant-locked callouts will automatically pick up the new
race-free semantics. This should close a number of race conditions
in the USB code and probably other areas of the kernel too.
There should be no change in behaviour for "MP-safe" callouts; these
still need to use the techniques mentioned in timeout(9) to avoid
race conditions.
when using the callout subsystem. Show how the callout_pending(),
callout_active() and callout_deactivate() macros can be used to
achieve simpler race-free callout semantics in many situations.
location of a PCI device in the system chassis.
Remove the note about PAE.
Update document date.
Update my email address.
Update copyright.
MFC after: 1 week
descriptions of items from each other and have related things appear
in the same nesting 'level'.
The .Fn function/macro, and bump document date.
Reviewed by: jkoshy
list for the valid flag values. This way, if VFS_UNMOUNT(9) supports
more flags in the future, adding a single list item is going to be
easy and all the flags are going to be in one place.
