[PATCH 00/21] On-demand device registration

[Alexander Holler]

Am 15.06.2015 um 10:58 schrieb Linus Walleij:
> On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler <holler at ahsoftware.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