Am 12.06.2015 um 13:19 schrieb Alexander Holler:
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler holler@ahsoftware.de wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system.
IAnd what happens if you run into a deadlock? Do you print "you've lost, try changing your kernel config" in some output hidden by a splash-screen? ;)
Sorry it sounds like a blanket argument, the fact that there are mutexes in the kernel makes it possible to deadlock, it doesn't mean we don't use mutexes. Some programming problems are just like such.
I'm not talking about specific deadlocks through mutexes. I'm talking about what happens when driver A needs driver B which needs driver A. How do you recognise and handle that with your instrumented on-demand device initialization? Such a circular dependency might happen by just adding a new fucntion call or by changing the kernel configuration. And with the on-demand stuff, the possibility that the developer introducing this new (maybe optional) call will never hit such a circular dependency is high. So you will end up with a never ending stream of problem reports whenever someone introduced such a circular dependecy without having noticed it.
And to come back to specific deadlocks, if you are extending function calls from something former simple to something which might initialize a whole bunch of drivers, needing maybe seconds, I wouldn't say this is a blanket argument, but a real thread.
Keep in mind, that the possibility that a function call ends up with initializing a whole bunch of other drivers, is not determined statically, but depends on the configuration and runtime behaviour of the actual system the on-demand stuff actually happens.
E.g. if driver A is faster one system that driver B, the whole bunch of drivers might become initialized by a call in driver A. But if driver B was faster on the developers system (or the system is configured to first init driver B), than the whole bunch of drivers might have become initialized by driver B on the developers system. Thus he never might have hit a possible problem when the whole bunch of drivers got initialized in driver A.
That means it isn't always a good idea to create dynamic systems (like on-demand device initialization), because it's very hard to foresee and correctly handle their runtime behaviour.
Alexander Holler