Messages in this thread | | | Date | Fri, 27 Oct 2006 18:50:41 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] drivers: wait for threaded probes between initcall levels |
| |
On Fri, 27 Oct 2006, Greg KH wrote: > > Heh, ok, I'll take this idea, and Andrew's patch, and rework things for > the next round of 2.6.20-rc kernels, and mark the current stuff as > BROKEN for now.
My interface stuff is kind of designed for:
- keep the current "init" sequence as-is for now
- keep the _actual_ PCI probing non-parallel, so that we actually do all the bus _discovery_ in a repeatable and sane order.
- use the new "execute_in_parallel()" interface for things that actually _sleep_. For example, all the PCI IDE _driver_ attachement should be done synchronously, but perhaps the code that tries to see if there are actual disks (ie the stuff that has timeouts etc) can use the parallel execution.
- module loading would do a "allow_parallel(1)" and "wait_for_parallel(1)" thing when calling the module init function (so that a module could use "execute_in_parallel()" whether compiled in or not, and each "init level" at boot would also do this (with some bigger number, like 10), so that for drivers etc that want to do async stuff, they can do so in parallel (but they'd still have done the actual hard device find/init serially - keeping the link order relevant for things like IDE controller discovery)
How does this sound?
There's really no reason to parallelise the actual PCI config cycles and probing and stuff. It's only when some driver knows that it might have to do some longer-running thing that it might want to execute a thread in parallel with other things - but it still needs to be done in a controlled situation, so that when "driver_init()" stops and "filesystem_init()" starts, we must wait for all the driver-init parallel tasks to finish (since "filesystem_init()" is allowed to depend on them).
Hmm?
Linus - 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/
| |