cvs commit: src/sys/amd64/amd64 local_apic.c src/sys/i386/acpica madt.c src/sys/i386/i386 local_apic.c src/sys/kern subr_smp.c src/sys/sun4v/mdesc mdesc_init.c

[Doug Rabson]

From: "Attilio Rao" <attilio at FreeBSD.org>
>> See above.  Are you going to go throw and assign a static order to ever 
>> device
>> driver now just in case the one's registration routine might someday 
>> depend
>> on another?
>
> Yes, and it doesn't sound so unreasonable.

It sounds silly to me. The only ordering requirement for registering drivers 
is that they should be registered before their parent bus is probed. This is 
simply accomplished by registering *all* drivers in one phase and then 
probing the device tree in a subsequent phase. Adding any extra ordering to 
this is pointless.

If two drivers have dependancies that requires them to be registered in a 
specific order, then my first reaction would be that they are doing 
something very wrong indeed. The only thing which changes if two drivers are 
registered in one order or another is the order that they will be offered 
devices during the probe. Drivers that depend on probe ordering with respect 
to other drivers are usually broken.