On Mon, Feb 16, 2009 at 1:15 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2009-02-16 at 01:09 -0800, Luis R. Rodriguez wrote: > >> We're strictly checking just for ENOMEMs which if you are getting will >> get you into problems anyway so might as well propagate that >> information. >> >> kobject_uevent_env() can fail for a short set of other non-memory >> related issues and those are the cases we are ignoring here including >> the possible call to call_usermodehelper() during early boot (which >> I'm not even sure how likely it is, Greg?). >> >> >, and then how is it different from crda >> > failing in userspace to warrant stopping cfg80211 from moving on? >> >> This is based on the premise that we are simply bailing out for all >> conditions on the creation of a udev event but that is not the case -- >> prior to this we were disregarding -ENOMEMs which I do not believe is >> correct. Why wouldn't you want to propagate that? > > Dunno, it just seems pointless to check for an error condition that > covers so few of the possible ways to fail here. RIght -- I hear ya, I am not sure how critical the other failures in kobject_uevent_env() are compared to -ENOMEM so this is why I didn't just propagate all errors and since one user already reported kobject_uevent_env() failing during initialization I was hesitant to simply let cfg80211 not be loaded because of this routine's failure. On the other hand, if we let -ENOMEM be propagated I believe it would be easier to narrow down failures of kobject_uevent_env() during intialization but I have to understand exactly how common those other possible failure are and for what reason. Luis -- 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
