Alex Chiang wrote: > * 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. Exactly. > Care to post dummyphp for us to see? http://opensource.sf-tec.de/kernel/dummyphp-2.6.28-rc7.diff Since I'm rather short on time it's not in a state I would like to see it in, i.e. I've not tested it for the last year. Greetings, Eike
Attachment:
signature.asc
Description: This is a digitally signed message part.
