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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 15.06.2015 um 10:58 schrieb Linus Walleij:
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler <holler@xxxxxxxxxxxxx> 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 dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux