On Thu, Apr 1, 2010 at 5:16 PM, Mauro Carvalho Chehab <mche...@redhat.com> >> What was the reason behind the asynchronous loading? In general it simplifies >> things a lot if you load modules up front. > > The reason is to avoid a dead lock: driver A depends on symbols on B (the > other driver init code) that depends on symbols at A (core stuff, locks, etc).
I believe these problems can be avoided with a common entry point for initializing the DVB submodule (where the loading of the subordinate module sets a pointer to a function for the main module to call). In fact, doesn't em28xx do that today with it's "init" function for its submodules? > There are other approaches to avoid this trouble, like the attach method used > by the DVB modules, but an asynchronous (and parallel) load offers another > advantage: it speeds up boot time, as other processors can take care of the > load of the additonal modules. I think though that we need to favor stability/reliability over performance. In this case, I have seen a number of bridges where having a "-dvb.ko" exposes this race, and I would much rather have it take another 200ms to load the driver than continue to deal with intermittent problems with hardware being in an unknown state. Don't quote me on this number, but on em28xx I run into problems about 20% of the time where the dvb device fails to get created successfully because of this race (forcing me to reboot the system). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
