On Fri, 23 Mar 2007 21:06:18 -0800,
Andrew Morton <akpm@linux-foundation.org> wrote:

quoted text
> Would I be right in guessing that this was all triggered by
> uevent-improve-error-checking-and-handling.patch?

Looks like it, since it passed the uevent failures to the upper layer.

quoted text
> If so, do you think I should labour on with
> uevent-improve-error-checking-and-handling.patch plus your fix, or should I
> drop the lot?  (I'm inclined toward the latter, but I'm still not
> sure which patch(es) need to be dropped).

This depends on what semantics uevent returning an error code should
have. The firmware code was using it to suppress uevents, but
uevent_suppress is a better idea now. So if we want uevent returning !=
0 to imply "something really bad happened", all uevent functions have
to be audited and those that work like firmware_uevent have to be
converted to uevent_suppress. This would be cleaner, but I'm not sure
it's worth the work.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/