lkml.org 
[lkml]   [2015]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/21] On-demand device registration
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


\
 
 \ /
  Last update: 2015-06-12 14:01    [W:0.128 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site