On Fri, Mar 26, 2021 at 11:50:44AM -0700, Alexander Duyck wrote: > My concern would be that we are defining the user space interface. > Once we have this working as a single operation I could see us having > to support it that way going forward as somebody will script something > not expecting an "offline" sysfs file, and the complaint would be that > we are breaking userspace if we require the use of an "offline" > file. Well, we wouldn't do that. The semantic we define here is that the msix_count interface 'auto-offlines' if that is what is required. If we add some formal offline someday then 'auto-offline' would be a NOP when the device is offline and do the same online/offline sequence as today if it isn't. > I almost wonder if it wouldn't make sense to just partition this up to > handle flexible resources in the future. Maybe something like having > the directory setup such that you have "sriov_resources/msix/" and This is supposed to be about PCI properties, that is why we are doing it in the PCI layer. If you want to see something that handles non-PCI properties too then Leon needs to make the whole thing general so the device driver can give a list of properties it wants to configure and the core manages the thing. But at that point, why involve the PCI core in the first place? Just put the complex configuration in the driver, use configfs or devlink or nvmecli or whatever is appropriate. And we are doing that too, there will also be pre-driver configuration in devlink for *non PCI* properties. *shrug* Jason
