[PATCH 00/21] On-demand device registration

[Alexander Holler]

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 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.

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