>> Would it make sense to add a "priority" argument to __initcall ?
>> This would allow to express simple dependencies between modules.
>> Of course this could be emulated by immediate functions that do
>> the traditional manual initialization.
> I've considered it, but there's no way I'll accept more than a
> small number of priorities. And no way in hell that I'll
> consider real dependencies to be acceptable.
Amen to that!
> What would be acceptable is something like:
> - three priorities: "CPU initialization", "bus initialization"
> and "driver initialization"
> - within each priority, the linking order can be used to
> sub-prioritize.
I can see five levels of priorities, as follows:
1. CPU initialisation. Until we've sorted out the CPU, the rest
is irrelevant.
2. Memory initialisation. We need to know what's available, and
how it should be used.
3. Bus initialisation. We can't guarantee to be able to access
the hardware until this has been done.
4. Hardware initialisation. Make sure that the hardware io and
IRQ is sensible. This deals with the various forms of PnP.
5. Driver initialisation. Do anything else that doesn't fall in
the above categories, such as setting sound card mixer levels.
Anything above that is meaningless, IMHO.
> Anything more complex than the above is almost certainly not a
> good idea, in my opinion. In fact, I'm not convinced even the
> above is acceptable. I do not want people to introduce
> dependencies: if there are dependencies then you might as well
> use the old-style "real initialization" sequence. The whole
> point of automatic initialization is to make it easy to add
> independent stuff.
Personally, I would see the above not as dependancies, but as a
general categorisation of the drivers into different stages of the
start-up process, so we can ensure that we deal with everything at a
specific level before starting with stuff that depends on that level
being set up.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/