On Tue, Oct 2, 2012 at 5:01 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Tue, 2 Oct 2012, Linus Torvalds wrote: > >> And see this email from Kay Sievers that shows that it was all known >> about and intentional in the udev camp: >> >> http://www.spinics.net/lists/netdev/msg185742.html > > This seems confusing indeed. > > That e-mail referenced above is talking about loading firmware at ifup > time. While that might work for network device drivers (I am not sure even > about that), what are the udev maintainers advice for other drivers, where > there is no analogy to ifup? Yeah, it's an udev bug. It really is that simple. This is why I'm complaining. There's no way in hell we're fixing this in kernel space, unless we call the "bypass udev entirely because the maintainership quality of it has taken a nose dive". Yes, I've seen some work-around patches, but quite frankly, I think it would be absolutely insane for the kernel to work around the fact that udev is buggy. The fact is, doing request_firmware() from within module_init() is simply the easiest approach for some devices. Now, at the same time, I do agree that network devices should generally try to delay it until ifup time, so I'm not arguing against that part per se. I do think that when possible, people should aim to delay firmware loading until as late as reasonable. But as you point out, it's simply not always reasonable, and the media people are clearly hitting the cases where it's just painful. Now, those cases seem to be happily fairly *rare*, so this isn't getting a ton of attention, but we should fix it. Because the udev behavior is all pain, no gain. There's no *reason* for udev to be pissy about this. And it didn't use to be. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
