On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote: > On Tue, 27 Mar 2007 11:25:57 +0200, > "Kay Sievers" <kay.sievers@xxxxxxxx> wrote: > > Checking the uevent return value, will not prevent any malfunction, > > usually this kind of "error handling" just prevents bringing up a > > whole subsystem, or booting-up a box, because the needed device does > > not exist at all. > > OK, if we consider uevents to be non-vital to a functioning device. The reason for that original patch was that it is actually possible for the uevent functions to return -ENOMEM, the uevent buffer being statically allocated to BUFFER_SIZE (2048). It used to be 1024 but that was not always enough and it was doubled a while ago [1]. Using add_uevent_var() makes this less of a problem as such an overflow should be catched cleanly [2]. > OTOH, I think using something like uevent_suppress (maybe via > dev_uevent_filter?) is a saner way to suppress a uevent than to return > an error code in the uevent function. That makes sense, I guess. I will try that. Thanks. [1] http://marc.info/?t=113797361200002&r=1&w=2 [2] uevent-use-add_uevent_var-instead-of-open-coding-it.patch in rc4-mm1 - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
