From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Date: Sat, 13 Jun 2015 18:27:21 +0000 Subject: Re: [PATCH 00/21] On-demand device registration Message-Id: <557C7609.30400@ahsoftware.de> List-Id: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> <5577F533.1060007@ahsoftware.de> <5579602F.1070801@ahsoftware.de> <5579B9E8.9040609@ahsoftware.de> <557AC040.40803@ahsoftware.de> <557AC437.9000607@ahsoftware.de> In-Reply-To: <557AC437.9000607@ahsoftware.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , dmaengine@vger.kernel.org, Tomeu Vizoso , "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Rob Herring , DRM PANEL DRIVERS , Grant Likely , Dan Williams , Dmitry Torokhov , linux-usb@vger.kernel.org, linux-i2c@vger.kernel.org Am 12.06.2015 um 13:36 schrieb 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 >>> 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. And because you've said that "problem space is a bit convoluted" and I disagree, here's a summary from my point of view: 1. All the necessary information (dependencies between drivers) already exists at compile time. The set of dependencies between drivers might become smaller by configuration, but will not become larger. So there should be NO need to collect them at runtime, e.g. by instrumenting function calls. I've described the problems I see with that above. I've choosen DT as source of dependencies because it offers an easy accessible and almost complete set of dependencies. I just had to add some type information to the dtb in order to identify the dependencies (phandles). But other ways to collect the dependencies would work too. Even the most simple way to add a static list of dependencies to each driver (which later on might be automated by some more clever stuff than adding them manually) would do the trick. 2. The problem to sort a set of nodes (drivers) with dependencies is solved since a long time and almost any developers uses it regularly in form of make. And everyone who used make -jN knows that the possible parallel initialization of drivers I've talked about, is already solved too. 3. In order to initialize the drivers in some specific order, their initcalls must be identified. I've offered a possible solution to that without much changes, but many other, even better ways, are possible too. It just depends on how much you want to change and on how much of these changes you will be able to feed into mainline kernel (which depends on your connections/relations inside the core kernel crew). E.g. instead of still just relying on one-dimensional arrays with (anonymous) pointers to initcalls, a multidimensional array of initcalls and drivername (and maybe more information) might be thinkable. 4. x86/amd64/ACPI-people, so most longtime and core kernel maintainers obviously don't have much interest until you've solved 1. in a way they can use too. So the necessary changes for 2. or 3. will have a big hurdle to take if 1. isn't solved usable for them too. >> Alexander Holler From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Subject: Re: [PATCH 00/21] On-demand device registration Date: Sat, 13 Jun 2015 20:27:21 +0200 Message-ID: <557C7609.30400@ahsoftware.de> References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> <5577F533.1060007@ahsoftware.de> <5579602F.1070801@ahsoftware.de> <5579B9E8.9040609@ahsoftware.de> <557AC040.40803@ahsoftware.de> <557AC437.9000607@ahsoftware.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <557AC437.9000607@ahsoftware.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , dmaengine@vger.kernel.org, Tomeu Vizoso , "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Rob Herring , DRM PANEL DRIVERS , Grant Likely , Dan Williams , Dmitry Torokhov , linux-usb@vger.kernel.org, linux-i2c@vger.kernel.org List-Id: linux-gpio@vger.kernel.org QW0gMTIuMDYuMjAxNSB1bSAxMzozNiBzY2hyaWViIEFsZXhhbmRlciBIb2xsZXI6Cj4gQW0gMTIu MDYuMjAxNSB1bSAxMzoxOSBzY2hyaWViIEFsZXhhbmRlciBIb2xsZXI6Cj4+IEFtIDEyLjA2LjIw MTUgdW0gMDk6MjUgc2NocmllYiBMaW51cyBXYWxsZWlqOgo+Pj4gT24gVGh1LCBKdW4gMTEsIDIw MTUgYXQgNjo0MCBQTSwgQWxleGFuZGVyIEhvbGxlcgo+Pj4gPGhvbGxlckBhaHNvZnR3YXJlLmRl PiB3cm90ZToKPj4+PiBBbSAxMS4wNi4yMDE1IHVtIDE0OjMwIHNjaHJpZWIgTGludXMgV2FsbGVp ajoKPj4+Cj4+Pj4+IENlcnRhaW5seSBpdCBpcyBwb3NzaWJsZSB0byBjcmVhdGUgZGVhZGxvY2tz IGluIHRoaXMgc2NlbmFyaW8sIGJ1dCB0aGUKPj4+Pj4gc2NvcGUgaXMgbm90IHRvIGNyZWF0ZSBh biB1YnJlYWthYmxlIHN5c3RlbS4KPj4+Pgo+Pj4+IElBbmQgd2hhdCBoYXBwZW5zIGlmIHlvdSBy dW4gaW50byBhIGRlYWRsb2NrPyBEbyB5b3UgcHJpbnQgInlvdSd2ZQo+Pj4+IGxvc3QsIHRyeQo+ Pj4+IGNoYW5naW5nIHlvdXIga2VybmVsIGNvbmZpZyIgaW4gc29tZSBvdXRwdXQgaGlkZGVuIGJ5 IGEKPj4+PiBzcGxhc2gtc2NyZWVuPyA7KQo+Pj4KPj4+IFNvcnJ5IGl0IHNvdW5kcyBsaWtlIGEg YmxhbmtldCBhcmd1bWVudCwgdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUKPj4+IG11dGV4ZXMgaW4g dGhlIGtlcm5lbCBtYWtlcyBpdCBwb3NzaWJsZSB0byBkZWFkbG9jaywgaXQgZG9lc24ndAo+Pj4g bWVhbiB3ZSBkb24ndCB1c2UgbXV0ZXhlcy4gU29tZSBwcm9ncmFtbWluZyBwcm9ibGVtcyBhcmUK Pj4+IGp1c3QgbGlrZSBzdWNoLgo+Pgo+PiBJJ20gbm90IHRhbGtpbmcgYWJvdXQgc3BlY2lmaWMg ZGVhZGxvY2tzIHRocm91Z2ggbXV0ZXhlcy4gSSdtIHRhbGtpbmcKPj4gYWJvdXQgd2hhdCBoYXBw ZW5zIHdoZW4gZHJpdmVyIEEgbmVlZHMgZHJpdmVyIEIgd2hpY2ggbmVlZHMgZHJpdmVyIEEuCj4+ IEhvdyBkbyB5b3UgcmVjb2duaXNlIGFuZCBoYW5kbGUgdGhhdCB3aXRoIHlvdXIgaW5zdHJ1bWVu dGVkIG9uLWRlbWFuZAo+PiBkZXZpY2UgaW5pdGlhbGl6YXRpb24/IFN1Y2ggYSBjaXJjdWxhciBk ZXBlbmRlbmN5IG1pZ2h0IGhhcHBlbiBieSBqdXN0Cj4+IGFkZGluZyBhIG5ldyBmdWNudGlvbiBj YWxsIG9yIGJ5IGNoYW5naW5nIHRoZSBrZXJuZWwgY29uZmlndXJhdGlvbi4gQW5kCj4+IHdpdGgg dGhlIG9uLWRlbWFuZCBzdHVmZiwgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIGRldmVsb3BlciBp bnRyb2R1Y2luZwo+PiB0aGlzIG5ldyAobWF5YmUgb3B0aW9uYWwpIGNhbGwgd2lsbCBuZXZlciBo aXQgc3VjaCBhIGNpcmN1bGFyIGRlcGVuZGVuY3kKPj4gaXMgaGlnaC4gU28geW91IHdpbGwgZW5k IHVwIHdpdGggYSBuZXZlciBlbmRpbmcgc3RyZWFtIG9mIHByb2JsZW0KPj4gcmVwb3J0cyB3aGVu ZXZlciBzb21lb25lIGludHJvZHVjZWQgc3VjaCBhIGNpcmN1bGFyIGRlcGVuZGVjeSB3aXRob3V0 Cj4+IGhhdmluZyBub3RpY2VkIGl0Lgo+Pgo+PiBBbmQgdG8gY29tZSBiYWNrIHRvIHNwZWNpZmlj IGRlYWRsb2NrcywgaWYgeW91IGFyZSBleHRlbmRpbmcgZnVuY3Rpb24KPj4gY2FsbHMgZnJvbSBz b21ldGhpbmcgZm9ybWVyIHNpbXBsZSB0byBzb21ldGhpbmcgd2hpY2ggbWlnaHQgaW5pdGlhbGl6 ZSBhCj4+IHdob2xlIGJ1bmNoIG9mIGRyaXZlcnMsIG5lZWRpbmcgbWF5YmUgc2Vjb25kcywgSSB3 b3VsZG4ndCBzYXkgdGhpcyBpcyBhCj4+IGJsYW5rZXQgYXJndW1lbnQsIGJ1dCBhIHJlYWwgdGhy ZWFkLgo+Cj4gS2VlcCBpbiBtaW5kLCB0aGF0IHRoZSBwb3NzaWJpbGl0eSB0aGF0IGEgZnVuY3Rp b24gY2FsbCBlbmRzIHVwIHdpdGgKPiBpbml0aWFsaXppbmcgYSB3aG9sZSBidW5jaCBvZiBvdGhl ciBkcml2ZXJzLCBpcyBub3QgZGV0ZXJtaW5lZAo+IHN0YXRpY2FsbHksIGJ1dCBkZXBlbmRzIG9u IHRoZSBjb25maWd1cmF0aW9uIGFuZCBydW50aW1lIGJlaGF2aW91ciBvZgo+IHRoZSBhY3R1YWwg c3lzdGVtIHRoZSBvbi1kZW1hbmQgc3R1ZmYgYWN0dWFsbHkgaGFwcGVucy4KPgo+IEUuZy4gaWYg ZHJpdmVyIEEgaXMgZmFzdGVyIG9uZSBzeXN0ZW0gdGhhdCBkcml2ZXIgQiwgdGhlIHdob2xlIGJ1 bmNoIG9mCj4gZHJpdmVycyBtaWdodCBiZWNvbWUgaW5pdGlhbGl6ZWQgYnkgYSBjYWxsIGluIGRy aXZlciBBLiBCdXQgaWYgZHJpdmVyIEIKPiB3YXMgZmFzdGVyIG9uIHRoZSBkZXZlbG9wZXJzIHN5 c3RlbSAob3IgdGhlIHN5c3RlbSBpcyBjb25maWd1cmVkIHRvCj4gZmlyc3QgaW5pdCBkcml2ZXIg QiksIHRoYW4gdGhlIHdob2xlIGJ1bmNoIG9mIGRyaXZlcnMgbWlnaHQgaGF2ZSBiZWNvbWUKPiBp bml0aWFsaXplZCBieSBkcml2ZXIgQiBvbiB0aGUgZGV2ZWxvcGVycyBzeXN0ZW0uIFRodXMgaGUg bmV2ZXIgbWlnaHQKPiBoYXZlIGhpdCBhIHBvc3NpYmxlIHByb2JsZW0gd2hlbiB0aGUgd2hvbGUg YnVuY2ggb2YgZHJpdmVycyBnb3QKPiBpbml0aWFsaXplZCBpbiBkcml2ZXIgQS4KPgo+IFRoYXQg bWVhbnMgaXQgaXNuJ3QgYWx3YXlzIGEgZ29vZCBpZGVhIHRvIGNyZWF0ZSBkeW5hbWljIHN5c3Rl bXMgKGxpa2UKPiBvbi1kZW1hbmQgZGV2aWNlIGluaXRpYWxpemF0aW9uKSwgYmVjYXVzZSBpdCdz IHZlcnkgaGFyZCB0byBmb3Jlc2VlIGFuZAo+IGNvcnJlY3RseSBoYW5kbGUgdGhlaXIgcnVudGlt ZSBiZWhhdmlvdXIuCgpBbmQgYmVjYXVzZSB5b3UndmUgc2FpZCB0aGF0ICJwcm9ibGVtIHNwYWNl IGlzIGEgYml0IGNvbnZvbHV0ZWQiIGFuZCBJIApkaXNhZ3JlZSwgaGVyZSdzIGEgc3VtbWFyeSBm cm9tIG15IHBvaW50IG9mIHZpZXc6CgoxLiBBbGwgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiAo ZGVwZW5kZW5jaWVzIGJldHdlZW4gZHJpdmVycykgYWxyZWFkeSAKZXhpc3RzIGF0IGNvbXBpbGUg dGltZS4gVGhlIHNldCBvZiBkZXBlbmRlbmNpZXMgYmV0d2VlbiBkcml2ZXJzIG1pZ2h0IApiZWNv bWUgc21hbGxlciBieSBjb25maWd1cmF0aW9uLCBidXQgd2lsbCBub3QgYmVjb21lIGxhcmdlci4g U28gdGhlcmUgCnNob3VsZCBiZSBOTyBuZWVkIHRvIGNvbGxlY3QgdGhlbSBhdCBydW50aW1lLCBl LmcuIGJ5IGluc3RydW1lbnRpbmcgCmZ1bmN0aW9uIGNhbGxzLiBJJ3ZlIGRlc2NyaWJlZCB0aGUg cHJvYmxlbXMgSSBzZWUgd2l0aCB0aGF0IGFib3ZlLiBJJ3ZlIApjaG9vc2VuIERUIGFzIHNvdXJj ZSBvZiBkZXBlbmRlbmNpZXMgYmVjYXVzZSBpdCBvZmZlcnMgYW4gZWFzeSAKYWNjZXNzaWJsZSBh bmQgYWxtb3N0IGNvbXBsZXRlIHNldCBvZiBkZXBlbmRlbmNpZXMuIEkganVzdCBoYWQgdG8gYWRk IApzb21lIHR5cGUgaW5mb3JtYXRpb24gdG8gdGhlIGR0YiBpbiBvcmRlciB0byBpZGVudGlmeSB0 aGUgZGVwZW5kZW5jaWVzIAoocGhhbmRsZXMpLiBCdXQgb3RoZXIgd2F5cyB0byBjb2xsZWN0IHRo ZSBkZXBlbmRlbmNpZXMgd291bGQgd29yayB0b28uIApFdmVuIHRoZSBtb3N0IHNpbXBsZSB3YXkg dG8gYWRkIGEgc3RhdGljIGxpc3Qgb2YgZGVwZW5kZW5jaWVzIHRvIGVhY2ggCmRyaXZlciAod2hp Y2ggbGF0ZXIgb24gbWlnaHQgYmUgYXV0b21hdGVkIGJ5IHNvbWUgbW9yZSBjbGV2ZXIgc3R1ZmYg dGhhbiAKYWRkaW5nIHRoZW0gbWFudWFsbHkpIHdvdWxkIGRvIHRoZSB0cmljay4KCjIuIFRoZSBw cm9ibGVtIHRvIHNvcnQgYSBzZXQgb2Ygbm9kZXMgKGRyaXZlcnMpIHdpdGggZGVwZW5kZW5jaWVz IGlzIApzb2x2ZWQgc2luY2UgYSBsb25nIHRpbWUgYW5kIGFsbW9zdCBhbnkgZGV2ZWxvcGVycyB1 c2VzIGl0IHJlZ3VsYXJseSBpbiAKZm9ybSBvZiBtYWtlLiBBbmQgZXZlcnlvbmUgd2hvIHVzZWQg bWFrZSAtak4ga25vd3MgdGhhdCB0aGUgcG9zc2libGUgCnBhcmFsbGVsIGluaXRpYWxpemF0aW9u IG9mIGRyaXZlcnMgSSd2ZSB0YWxrZWQgYWJvdXQsIGlzIGFscmVhZHkgc29sdmVkIHRvby4KCjMu IEluIG9yZGVyIHRvIGluaXRpYWxpemUgdGhlIGRyaXZlcnMgaW4gc29tZSBzcGVjaWZpYyBvcmRl ciwgdGhlaXIgCmluaXRjYWxscyBtdXN0IGJlIGlkZW50aWZpZWQuIEkndmUgb2ZmZXJlZCBhIHBv c3NpYmxlIHNvbHV0aW9uIHRvIHRoYXQgCndpdGhvdXQgbXVjaCBjaGFuZ2VzLCBidXQgbWFueSBv dGhlciwgZXZlbiBiZXR0ZXIgd2F5cywgYXJlIHBvc3NpYmxlIAp0b28uIEl0IGp1c3QgZGVwZW5k cyBvbiBob3cgbXVjaCB5b3Ugd2FudCB0byBjaGFuZ2UgYW5kIG9uIGhvdyBtdWNoIG9mIAp0aGVz ZSBjaGFuZ2VzIHlvdSB3aWxsIGJlIGFibGUgdG8gZmVlZCBpbnRvIG1haW5saW5lIGtlcm5lbCAo d2hpY2ggCmRlcGVuZHMgb24geW91ciBjb25uZWN0aW9ucy9yZWxhdGlvbnMgaW5zaWRlIHRoZSBj b3JlIGtlcm5lbCBjcmV3KS4gRS5nLiAKaW5zdGVhZCBvZiBzdGlsbCBqdXN0IHJlbHlpbmcgb24g b25lLWRpbWVuc2lvbmFsIGFycmF5cyB3aXRoIChhbm9ueW1vdXMpIApwb2ludGVycyB0byBpbml0 Y2FsbHMsIGEgbXVsdGlkaW1lbnNpb25hbCBhcnJheSBvZiBpbml0Y2FsbHMgYW5kIApkcml2ZXJu YW1lIChhbmQgbWF5YmUgbW9yZSBpbmZvcm1hdGlvbikgbWlnaHQgYmUgdGhpbmthYmxlLgoKNC4g eDg2L2FtZDY0L0FDUEktcGVvcGxlLCBzbyBtb3N0IGxvbmd0aW1lIGFuZCBjb3JlIGtlcm5lbCBt YWludGFpbmVycyAKb2J2aW91c2x5IGRvbid0IGhhdmUgbXVjaCBpbnRlcmVzdCB1bnRpbCB5b3Un dmUgc29sdmVkIDEuIGluIGEgd2F5IHRoZXkgCmNhbiB1c2UgdG9vLiBTbyB0aGUgbmVjZXNzYXJ5 IGNoYW5nZXMgZm9yIDIuIG9yIDMuIHdpbGwgaGF2ZSBhIGJpZyAKaHVyZGxlIHRvIHRha2UgaWYg MS4gaXNuJ3Qgc29sdmVkIHVzYWJsZSBmb3IgdGhlbSB0b28uCgo+PiBBbGV4YW5kZXIgSG9sbGVy CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753742AbbFMS2B (ORCPT ); Sat, 13 Jun 2015 14:28:01 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:42522 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbbFMS1s (ORCPT ); Sat, 13 Jun 2015 14:27:48 -0400 Message-ID: <557C7609.30400@ahsoftware.de> Date: Sat, 13 Jun 2015 20:27:21 +0200 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Linus Walleij CC: Tomeu Vizoso , Grant Likely , Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , "linux-tegra@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "linux-kernel@vger.kernel.org" , Rob Herring , "linux-pwm@vger.kernel.org" , DRM PANEL DRIVERS , dmaengine@vger.kernel.org, Dan Williams , linux-usb@vger.kernel.org, linux-i2c@vger.kernel.org Subject: Re: [PATCH 00/21] On-demand device registration References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> <5577F533.1060007@ahsoftware.de> <5579602F.1070801@ahsoftware.de> <5579B9E8.9040609@ahsoftware.de> <557AC040.40803@ahsoftware.de> <557AC437.9000607@ahsoftware.de> In-Reply-To: <557AC437.9000607@ahsoftware.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 12.06.2015 um 13:36 schrieb 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 >>> 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. And because you've said that "problem space is a bit convoluted" and I disagree, here's a summary from my point of view: 1. All the necessary information (dependencies between drivers) already exists at compile time. The set of dependencies between drivers might become smaller by configuration, but will not become larger. So there should be NO need to collect them at runtime, e.g. by instrumenting function calls. I've described the problems I see with that above. I've choosen DT as source of dependencies because it offers an easy accessible and almost complete set of dependencies. I just had to add some type information to the dtb in order to identify the dependencies (phandles). But other ways to collect the dependencies would work too. Even the most simple way to add a static list of dependencies to each driver (which later on might be automated by some more clever stuff than adding them manually) would do the trick. 2. The problem to sort a set of nodes (drivers) with dependencies is solved since a long time and almost any developers uses it regularly in form of make. And everyone who used make -jN knows that the possible parallel initialization of drivers I've talked about, is already solved too. 3. In order to initialize the drivers in some specific order, their initcalls must be identified. I've offered a possible solution to that without much changes, but many other, even better ways, are possible too. It just depends on how much you want to change and on how much of these changes you will be able to feed into mainline kernel (which depends on your connections/relations inside the core kernel crew). E.g. instead of still just relying on one-dimensional arrays with (anonymous) pointers to initcalls, a multidimensional array of initcalls and drivername (and maybe more information) might be thinkable. 4. x86/amd64/ACPI-people, so most longtime and core kernel maintainers obviously don't have much interest until you've solved 1. in a way they can use too. So the necessary changes for 2. or 3. will have a big hurdle to take if 1. isn't solved usable for them too. >> Alexander Holler