On Wed, 9 Dec 2009, Alan Stern wrote: > > In fact these considerations already affect the USB resume operations, > even without asynchronous resume. The code relies on the fact that the > PCI layer registers sibling devices on a slot in order of increasing > function number. There's no guarantee this will remain true in the > future (it may already be wrong AFAIK), so putting in some explicit > list manipulation is the prudent thing to do. I do think we want to keep the slot ordering. One of the silent issues that the device management code has always had is the whole notion of naming stability. Now, udev and various fancy naming schemes solve that at a higher level, but it is still the case that we _really_ want basic things like your PCI controllers to show up in stable order. For example, it is _very_ inconvenient if things like PCI probing ends up allocating different bus numbers (or resource allocations) across reboots even if the hardware hasn't been changed. Just from a debuggability standpoint, that just ends up being a total disaster. For example, we continually hit odd special cases where PCI resource allocation has some unexplained problem because there is some motherboard resource that is hidden and invisible to our allocator. They are rare in the sense that it's usually just a couple of odd laptops or something, but they are not rare in the sense that pretty much _every_ single time we change some resource allocation logic, we find one or two machines that have some issue. Things like that would be total disasters if the core device layer then ended up also not having well-defined ordering. This is why I don't want to do asynchronous PCI device probing, for example (ie we probe the hardware synchronously, the PCI driver sets it all up synchronously, and the asynchronous portion is the non-PCI part if any - things like PHY detection, disk spinup etc). So async things are fine, but they have _huge_ disadvantages, and I'll personally take reliability and a stable serial algorithm over an async one as far as possible. That's partly why I realy did suggest that we do the async stuff purely in the USB layer, rather than try to put it deeper in the device layer. And if we do support it "natively" in the device layer like Rafael's latest patch, I still think we should be very very nervous about making devices async unless there is a measured - and very noticeable - advantage. So I really don't want to push things any further than absolutely necessary. I do not think that something like "embedded audio" is a reason for async, for example. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
