On 08/04/2014 08:45 AM, Edward Cree wrote: > On 02/08/14 01:25, Ethan Zhao wrote: >> 在 2014年8月1日，下午8:15，Edward Cree <ecree@xxxxxxxxxxxxxx> 写道： >>> On 01/08/14 04:51, Ethan Zhao wrote: >>>> So far seems no driver call pci_sriov_set_totalvfs() with numvfs = 0 >>>> and the patch will change the behavior of the drivers, but it will >>>> definitely change the test cases and documents related to IOV. >>> As for test cases and documents, I can't find any in the kernel tree >> I mean some test cases or doc that are out of kernel tree ... such as some Distro, >> not only Hardware vendors. > I was under the impression that we don't care about breaking out-of-tree > code. Distros should be (and it looks like most are) using the > kernel-doc to generate their documentation, and the kernel-doc doesn't > say anything about what happens when passing 0. > > -Edward Edward, The concern isn't what is out there, but what will come of it as a result. The question is should we allow setting the value to 0 to change the behavior from disabling the override to essentially disabling SR-IOV. If we consider it acceptable to use 0 as a disable value, and there are several people on this thread that don't, the secondary issue of this is the error return for sriov_numvfs_store which hasn't been addressed. Should we still be returning ERANGE if SR-IOV has essentially been disabled, or should we be returning some other error such as EBUSY, ENOMEM, ENODEV, or ENOSYS to indicate that there are no resources available for SR-IOV. I think you would be much better off just implementing sriov_configure for your PCI driver and placing your own error return there if you cannot allocate a vswitch. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
