On Tue, Sep 25, 2012 at 1:06 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > On Tue, Sep 25, 2012 at 1:53 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >> On Tue, Sep 25, 2012 at 12:45 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> >>> Sure, it might be *safe*. But it's not *sufficient*. If you use >>> for_each_pci_host_bridge(), you also need to do something else to deal >>> with hot-added host bridges. It's hard to make sure that every caller >>> does both parts correctly: >>> >>> 1) for_each_pci_host_bridge() for things we've already seen and >>> 2) some sort of notifier for hot-added bridges >> >> yes. >> >>> >>> That's why I'd prefer a single interface. >> >> that will have draw backs too: >> 1. too much changes to the code of current caller. >> 2. have to checking system_state back and forth. >> 3. some variable function call may only need for _init path could not be freed. >> or add annoying _ref_ok etc. > > We already have to make significant changes to the callers. Your > changes only address part 1. More changes will be needed for part 2, > and they will look very much like the approach I'm suggesting. not that much, We just update the loop function from the caller. > > I'm frankly dubious about your fears of system_state and __init > complexity. PCI enumeration and driver binding already happens late > enough that the system is almost completely initialized. But I guess > we won't know for sure until we try out both ideas. it is all up to the caller to decide it initial path for_ loop is enough, or they still need part 2, or later they could even remove part1 and only keep part2 if the those function can survive the initial boot path. -Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
