On Mon, 06 Aug 2007 22:23:07 +0200, Javier Pello <[EMAIL PROTECTED]> wrote:
> > > 2. The second part changes _request_firmware in > > > drivers/base/firmware_class.c to actually check the return value > > > of kobject_uevent and skip the loading_timeout delay if the > > > loading event was not delivered to userspace at all. > > > > Note that kobject_uevent() returns 0 if the event has been filtered. > > Oops, yes, I had not noticed. This brings another point: When should > kobject_uevent return a "failure"? The code, as it is, only returns a > failure when things are really wrong (out of memory, etc.), and > returns success when the event was simply dropped. This is reasonable > behaviour, but it prevents callers from knowing whether the event was > actually delivered (which is what request_firmware needs). On the > other hand, my patch tries to make nondelivery an error, but on > second thoughts that could prevent the caller from telling hard > errors from simple nondelivery. You could say that not delivering is caused by a hard error when trying to deliver, though. OTOH, filtering an event is certainly not an error. > I can think of two possibilities > to sort this out: > > - kobject_uevent returns an error code both on a hard error and > on nondelivery; the error codes for both situations are different, > so the caller can tell them apart. Tough. For example, both today's kobject_uevent() and call_usermodehelper() may return -ENOMEM. > > - kobject_uevent returns an error code (<0) only on a hard error, > returns 0 on nondelivery and 1 on delivery; this makes things > even clearer. Hm, I have an aversion against tri-state return values :( OTOH, a) callers generally don't care and b) it is in line with how kobject_uevent() is defined if !CONFIG_HOTPLUG. - Use an extra parameter in which successful delivery can be indicated. Make this int kobject_uevent_env_check(struct kobject *kobject, enum kobject_action action, char *envp[], int delivered); so existing callers that don't care don't have to be changed. > > I am biased towards the latter. Of course, we can do anything as > the return value is actually never used, but I would still like > to know other opinions about what the right thing is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/