On Tue, 15 Jun 2021 17:42:16 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Tue, Jun 15, 2021 at 10:20:49AM -0600, Alex Williamson wrote: > > On Tue, 15 Jun 2021 12:04:58 -0300 > > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > > On Tue, Jun 15, 2021 at 09:00:29AM -0600, Alex Williamson wrote: > > > > > > > "vfio" override in PCI-core plays out for other override types. Also I > > > > don't think dynamic IDs should be handled uniquely, new_id_store() > > > > should gain support for flags and userspace should be able to add new > > > > dynamic ID with override-only matches to the table. Thanks, > > > > > > Why? Once all the enforcement is stripped out the only purpose of the > > > new flag is to signal a different prepration of modules.alias - which > > > won't happen for the new_id path anyhow > > > > Because new_id allows the admin to insert a new pci_device_id which has > > been extended to include a flags field and intentionally handling > > dynamic IDs differently from static IDs seems like generally a bad > > thing. > > I'd agree with you if there was a functional difference at runtime, > but since that was all removed, I don't think we should touch new_id. > > This ends up effectively being only a kbuild related patch that > changes how modules.alias is built. But it wasn't all removed. The proposal had: a) Short circuit the dynamic ID match b) Fail a driver-override-only match without a driver_override c) Fail a non-driver-override-only match with a driver_override Max is only proposing removing c). b) alone is a functional, runtime difference. As per my previous example, think about using it as effectively an anti-match. Userspace can create dynamic entries that will be matched before static entries that can demote a driver to not be able to bind to a device automatically. That's functional and useful, I can't think of any other way we have to effectively remove a static match entry from a driver. Thanks, Alex
