Alex Chiang wrote:
> * Trent Piepho <xyzzy@xxxxxxxxxxxxx>:
> > On Mon, 1 Dec 2008, Alex Chiang wrote:
> > > I think there are now enough ideas in this thread that they're
> > > starting to get confusing.
> > >
> > > 1) Function vs. device removal
> > > 2) User interface
> > > 3) Existing fakephp bugs
> > >
> > > For (1), do you need function level hotplug? Or will you be able
> > > to get away with device level?
> >
> > While I have some hardware the can use function level hotplug (secondary
> > functions can be controlled by registers in the primary function), it's
> > not something *I* make use of. But function level hotplug has been there
> > for years so it seems like a regression to remove that ability and break
> > the existing interface.
>
> That seems reasonable.
>
> > I guess my first though is should be there a new interface, as part of
> > the pci core rather than pci hotplug, for adding/removing devices from
> > Linux's view? By devices I mean in the Linux "struct device" sense, so
> > PCI functions.
> >
> > I think that seems reasonable. fakephp isn't the best interface. My
> > patch to add "remove" to pci-sysfs ended up being very simple, unless
> > there's a serious flaw in it I've overlooked.
>
> I think we should definitely merge your 'remove' attribute patch
> for PCI functions. That should be independent of the rest of our
> discussion.
>
> It will probably help the SR-IOV folks too.
>
> > So once we have that the question becomes how to keep some compatibility
> > with the old fakephp interface. Either a new legacy compat module like
> > I've done or by fixing fakephp.
> >
> > I'm more inclined to have the new legacy compat module:
> >
> > - It's quite a bit simpler than fakephp so far.
> > - It already works better than fakephp ever did. fakephp can't do
> > recursive bridge removal and won't co-exist well with a new pci core
> > remove/add interface.
> > - Fakephp's use of devices as "slots" appears to be fundamentally at odds
> > with the hotplug core. It's just going to cause problems in the future.
> > The new compat module doesn't use hotplug at all, so it shouldn't get in
> > the way.
>
> Maybe we should just replace fakephp wholesale with your new
> driver?
>
> Or coming at it from another angle, I don't see what benefit
> we'll have from keeping both fakephp and your driver. And if
> fakephp is as broken as you describe, then it will only cause
> more confusion if a user loads both fakephp and legacy_fakephp.
>
> If the user removes a bridge via the correct legacy_fakephp
> interface, fakephp won't notice, and we'll just have a broken
> mess on our hands.
>
> It would be better to have just one, correctly working fakephp,
> even if the implementation is 100% different and truly not even a
> "real" hotplug driver.
>
> I think the way forward is:
>
> - merge in the function level hotplug patch
Sorry that I don't get the point. To PCI Hotplug core or to fakephp?
> - wholesale replacement of fakephp with new fakephp
> - schedule new fakephp for deprecation
^^^
I don't think so.
> - 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.
Eike
Attachment:
signature.asc
Description: This is a digitally signed message part.
