2015-08-31 08:59, Neil Horman: > On Mon, Aug 31, 2015 at 10:23:33AM +0000, Iremonger, Bernard wrote: > > The purpose of this RFC is to remove the need for a PCI device driver > > from Vdev's that that do not use a PCI driver. Removing the PCI driver > > is implemented in the ethdev changes. I have modified some of the Vdev's > > to verify that the ethdev changes work. > > > You didn't remove the relationship of the ethdev to the pci driver though, > which > is really the problem, An ethdev may reside on any number of bus types > (pci/usb/vmbus/virt/none). This patch series just papers over the fact that > an > ethdev is implicitly a pci device by making the assignment of its pci_dev > pointer optional. Whats really needed is a way to associate an ethdev with an > arbitrary bus > > > > What benefit accrues to those vdev > > > PMDs that implement this change? What penalty is imposed on those that > > > do not change? > > > > 6Wind have decided that only cleanup patches will be allowed in future
Not a 6WIND decision. This is a community project. I gave my opinion regarding maintenance of the code. I may be wrong but after discussions with others and recent comments, it seems well justified. > > for Vdevs that have a dummy PCI driver. Any change in functionality for > > these Vdevs will not be allowed. > > Please see email below from 6Wind > > > > http://dpdk.org/ml/archives/dev/2015-July/022107.html > > > I think you misread that. I think all Thomas is asking for (correct me if I'm > wrong Thomas), is for someone to start refactoring the ethdev registration > code > so that we can have a single init path without the need for wierd typing and > differentiation at init time. He's not going to stop accepting bug fixes for > existing drivers just because it uses the existing initalization > infrastructure. Yes. Such cleanup can be enforced by rejecting new features on top of these workarounds. But driver fixes will be accepted. > I would even go so far as to say new drivers will be accepted for as long as > the > existing init path exists as it does. We just need to start thinking about > how > to make bus registration independent of ethernet device registration, and > while > your patch series sort of eliminates some of that, its really not a proper > refactoring of the sort I think Thomas is asking for Yes The sooner will be the better :) Thanks for taking care of this issue.
