Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754295AbbFLLTs (ORCPT ); Fri, 12 Jun 2015 07:19:48 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:43325 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbbFLLTm (ORCPT ); Fri, 12 Jun 2015 07:19:42 -0400 Message-ID: <557AC040.40803@ahsoftware.de> Date: Fri, 12 Jun 2015 13:19:28 +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> In-Reply-To: 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 Content-Length: 1858 Lines: 37 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. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/