Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754152AbbFOJnZ (ORCPT ); Mon, 15 Jun 2015 05:43:25 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:43742 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753425AbbFOJnM (ORCPT ); Mon, 15 Jun 2015 05:43:12 -0400 Message-ID: <557E9E1A.7060000@ahsoftware.de> Date: Mon, 15 Jun 2015 11:42:50 +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> <557C7609.30400@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: 3187 Lines: 68 Am 15.06.2015 um 10:58 schrieb Linus Walleij: > On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler wrote: > >> 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 think you arrived at the core of the crux here. I've hoped so, that's why I've written it. > I guess your suggested approach then need to introduce a special > build tool to order the initcalls accordingly. > > Again this will fall short if you don't know at compile time exactly > *which* board file will be executed. I've just tried to describe the facts in order to make the problem space more clear, because, as said, I don't think it's convoluted. Besides that, I didn't want to suggest anything else other than what I've already posted working patches for. What I've mentioned as possible other solutions above is stuff which might be possible too in order to give some starting points for people which are searching another solution. But I wouldn't have written my patches as they are, if I would think there is another more easier solution. And of course, there is still a bit to resolve at runtime, even in the DT case (look at the "compatible" attribute). But there is already a runtime solution to find the right driver (in case of DT) and I haven't mentioned it in order to no confuse people again. Mentioning every little detail doesn't make sense if you want to describe something understandable (which is what I've tried). > So the only practical way to solve this at compile time is to predict > an initcall ordering sequence for all possible boot paths, compile in > all of them, and choose the right one at boot. But the number of boot > paths is equal to the number of device trees / ACPI tables or > board files supported, and that space is uncontrolled and ordered > infinite. You just need one working ordered sequence which includes all options. This one will work for all others too. > Basically I think the root problem with your approach is that you > assume we know what hardware we will boot on at compile time. We Totally wrong. If you assume that I assume this, than either I was totally unable to describe something clearly, or you were unable or unwilling to understand what I've written. And as the result is the same, we don't need to find out which was reason. Anyway, have fun. I'm quitting the discussion here as I don't have any business with the kernel and already decided some time again to not post patches anymore as it seems to be a waste of my (and maybe others) time. Regards, 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/