* Rolf Eike Beer <eike-kernel@xxxxxxxxx>: > Alex Chiang wrote: > > * Rolf Eike Beer <eike-kernel@xxxxxxxxx>: > > > Alex Chiang wrote: > > > > - wholesale replacement of fakephp with new fakephp > > > > - schedule new fakephp for deprecation > > > > > > ^^^ > > > > > > I don't think so. > > > > If we get function level reset as part of the PCI core, then I > > don't see what fakephp offers us anymore. > > Why add a new fakephp if you want to remove it right after that? How we got here: - we made changes to PCI core that says, "/sys/bus/pci/slots/ is for _physical_ slots" - that series of changes broke an existing interface (fakephp) that had real users - the existing interface was interesting because it was the only way that allowed for function level hotplug So, if we can get function level hotplug via a different interface (by adding a "remove" attribute to pci-sysfs), then I don't really see a strong reason to keep fakephp. We also don't want to break existing software (more than we already have :-/ ) so we need a transition period to get users over to the new "remove" interface. A deprecation period is usually pretty long, several years, iirc. > > > > - encourage anyone who wants function level > > > > hotplug to use the 'remove' attribute > > > > > > > > Thoughts? Jesse, Willy, Eike, Greg? > > > > > > Oh yes, let's start using dummyphp ;) That one already > > > handled the rescan long ago. But I think it's a bit > > > outdated at the moment, I haven't touched it for month. > > > Looks like I need to bring it back to live. > > > > I take it you are not impressed with my proposal? Care to > > explain why not? > > It's a long fight between me and Greg about fakephp. I wrote > dummyphp, fakephp is a for of an early version of dummyphp that > I never liked. So if anyone comes up with "fakephp can not do > $foobar" my first answer is "try dummyphp". So if you want to > remove fakephp I'm the first do support you *eg* Yes, this > probably is mostly personal taste and not so much technical, > but I'm just human ;) Ok, well I haven't seen dummyphp. I don't think we should really care that much about dummyphp vs. new fakephp as long as we complete the end goal, which in my opinion is: /sys/bus/pci/slots/ represents physical slots and device hotplug /sys/devices/<bus>/<function>/remove used for function hotplug If we can use dummyphp to get us through the transition period, meaning it can: - provide an interface compatible with fakephp - allow recursive hotplug (remove a bridge and all functions behind it) - recognize if a function has been hotplugged via a different interface - relatively simple implementation Then I'm sure that Trent won't mind whether we use your dummyphp or his new fakephp. I'm wondering though, if dummyphp uses the PCI hotplug API, it will probably suffer from the same limitation that the current fakephp does, which is that the PCI hotplug core will only allow drivers to claim on a _device_ level, not _function_ level. Care to post dummyphp for us to see? Thanks. /ac -- 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
