Messages in this thread | | | Date | Tue, 7 Aug 2007 12:58:44 +0200 | From | Cornelia Huck <> | Subject | Re: [PATCH] request_firmware: skip timeout if userspace was not notified |
| |
On Mon, 06 Aug 2007 22:23:07 +0200, Javier Pello <javier.pello@urjc.es> 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 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/
| |