On Sun, 2010-03-21 at 20:10 +0100, Andi Kleen wrote: > Ben Hutchings <b...@decadent.org.uk> writes: > > > WARN() is used in some places to report firmware or hardware bugs that > > are then worked-around. These bugs do not affect the stability of the > > kernel and should not set the usual TAINT_WARN flag. To allow for > > this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint > > flag as argument. > > > > Architectures that implement warnings using trap instructions instead > > of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) > > instead of __WARN(). > > I guess this should enforce that at least some taint flag is set? > (e.g. with a BUILD_BUG_ON)
I'm being a bit sloppy with the wording here. The TAINT_* macros are
actually bit numbers, not flags. I could define a TAINT_MAX and add:
BUILD_BUG_ON(taint < 0 || taint > TAINT_MAX);
Not sure that that's really worth doing though.
Ben.
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
