Re: [PATCH 00/21] On-demand device registration

[Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>]

Am 12.06.2015 um 09:25 schrieb Linus Walleij:
> On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html