Message-Id: <200812082209.57172.eike-kernel@sf-tec.de>
Date:	Mon, 8 Dec 2008 22:09:53 +0100
From:	Rolf Eike Beer <eike-kernel@...tec.de>
To:	Alex Chiang <achiang@...com>
Cc:	Trent Piepho <xyzzy@...akeasy.org>,
	"Darrick J. Wong" <djwong@...ibm.com>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-pci" <linux-pci@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>, gregkh@...e.de
Subject: Re: Problems with fakephp

Alex Chiang wrote:
> * Rolf Eike Beer <eike-kernel@...tec.de>:
> > Alex Chiang wrote:
> > > * Rolf Eike Beer <eike-kernel@...tec.de>:
> > > > 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

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists