Re: [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@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/