Am 12.06.2015 um 09:25 schrieb Linus Walleij: > On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler <holler at 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. Alexander Holler
