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 linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
