> > I'm not sure we should go this way. My main problem is that it only solves
> > a single ordering problem - boot time ordering. What about suspend/wakeup?
> > We have more of these ordering problems and driverfs is supposed to help
> > with them, so I'd rather first would like to see how much we can fix this
> > way.
>
> suspend/wakeup is a device issue, solved well by devicefs. This is
> completely independent from the subtleties of initialization order in
> the core kernel code: devices are not the problem.
>
> Look at how many places have explicit initializers with #ifdef
> CONFIG_XXX around them, because initialization order problems were too
> hard before. These can now be fixed as desired.
>
> I really want *one* place where you can see what order things are
> initalized. If that means one big file with #ifdef's, fine. But the
> current approach of using link order, initializer levels and explicit
> initializers is really hard to debug and modify.
Since I'm still CC'ed, I thought I could add in my 2 cents, too ;)
I agree with Rusty, his ordered initcalls are really needed most at early
points during the system initialization, way before device discovery and
initialization. They allow for a lot of cleanup and clarification in that
area, so I definitely think they should go in.
Those initcalls that only do pci_register_driver() and the like are
typically the module_init() functions and are taken care of by Roman's
patch. Also, inserting devices into the device tree and handling them can
only happen after the kernel knows about the drivers, which it only does
after the corresponding initcall has run. The place where to insert them
is however an entirely different story, and that's handled by the device
tree just fine.
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/