On Sun, 2010-03-21 at 20:10 +0100, Andi Kleen wrote: > Ben Hutchings <ben@xxxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
