> > >Currently the kerenl will call probe for any device for which there > > >is a supporting driver and I did not want to change that. > > > > But what's next? How will this feature be activated? > > > > Adding a parameter to pci_enable_sriov() might give developers the > > false impression they can change behavior by passing `0' to this > > function; But that shouldn't be the method to control this - we should > > have uniform control of the feature across different drivers, e.g., by an > additional sysfs node. > > I was planning on using this on mlx5 SRIOV support which is not available > upstream yet. So this could be a driver developer's decision how to use this. I think it shouldn't - from user perspective, you can't have such fundamental difference between different drivers - that enabling sriov on one device would create VFs in the hypervisors and another one won't. > I think adding another sysfs entry to control this behavior is unnecessary since the > administrator has the freedom to later do any bidnings he wishes to do. > > Keeping things as they are today is not so "nice". I mean, I could fail probe for > VFs to avoid them from being initialized at the hypervisor but there are other > questions: which error should I return and how can I be sure how the bus driver > will refer to such failures. Again - you could say that this is solely in your drivers decision-making-area, but failing the VF probe would lead to the same difference between drivers I've stated before. > So, maybe the solution I suggested is not the best one but do we agree that this > needs to be addressed this way or another? All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
<<attachment: winmail.dat>>
