On Sun, 9 Dec 2007, David Brownell wrote: > > > FWIW the appended patch removes that rude "order of registration" > > > > "Rude"? What's rude about it? It seems most logical to me: Since the > > devices obviously worked in the intermediate stages of registration, > > ... > > Rude because it keeps things implicit which should be explicit. Your patch isn't really much better (IMHO). While its order may be less "random" in the sense that it is determined by the device tree, the tree itself is somewhat random and not fully determined by the physical hardware layout. It is affected by the order in which drivers are loaded, or the order in which PCI cards are probed, and so on. And in any case, having a fixed order doesn't move us any closer to the goal of making all the dependencies explicit. > Such a random visitation seems like a clear problem when a > goal is to introduce parallelism ... So does a strict depth-first visitation. Or indeed, any fixed ordering, since parallelism will involve indeterminacy. > Nope; what we need is the ability to finger "this specific device > has dependencies that aren't explicit". Being able to introduce > random failures isn't really helpful. It's the difference between > being able to use lockdep vs. having to wait until a random locking > failure crops up in a way that can usefully be diagnosed. I agree. Even better would be to say "this specific device has this specific dependency". But it's not easy to come up with strategies for finding this information. There's no clear-cut analog to lockdep. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
