Re: Problems with fakephp

[Alex Chiang]

* 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/