linux-kernel - Re: [PATCH 00/21] On-demand device registration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <557E9E1A.7060000@ahsoftware.de>
Date:	Mon, 15 Jun 2015 11:42:50 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
	DRM PANEL DRIVERS <dri-devel@...ts.freedesktop.org>,
	dmaengine@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH 00/21] On-demand device registration

Am 15.06.2015 um 10:58 schrieb Linus Walleij:
> On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler <holler@...oftware.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/