On Thu, 26 Feb 2026 at 17:32, Bruce Richardson
<[email protected]> wrote:
> > +RTE_EXPORT_INTERNAL_SYMBOL(rte_bus_is_ignored_device)
> > +bool
> > +rte_bus_is_ignored_device(const struct rte_bus *bus, const struct
> > rte_devargs *devargs)
> > +{
> > + switch (bus->conf.scan_mode) {
> > + case RTE_BUS_SCAN_ALLOWLIST:
> > + if (devargs && devargs->policy == RTE_DEV_ALLOWED)
> > + return false;
> > + break;
> > + case RTE_BUS_SCAN_UNDEFINED:
> > + case RTE_BUS_SCAN_BLOCKLIST:
> > + if (devargs == NULL || devargs->policy != RTE_DEV_BLOCKED)
> > + return false;
> > + break;
> > + }
> > + return true;
> > +}
>
> I think this could do with more comments. Am I right in thinking that
> devargs is NULL on input if the device in question is not referenced by any
> devargs passed to the app? This seems a little obscure form of input
> parameter, so I definitely think it needs documenting.
Yes the handling of a NULL devargs is implicit, I can add a comment.
> Is there any way the search for the device name that returns the devargs
> null/non-null pointer can be similarly generalized?
I also wondered about that and it would be better, but I stopped
quickly when I looked at the bus specific devargs_lookup functions,
preparing the v2.
For example with the pci bus, names for pci devices can take various
forms, so the pci bus uses its device specific representation for
identifying the devargs.
rte_pci_device_name(&dev->addr,
dev->name, sizeof(dev->name));
devargs = pci_devargs_lookup(&dev->addr);
And:
RTE_EAL_DEVARGS_FOREACH("pci", devargs) {
devargs->bus->parse(devargs->name, &addr);
if (!rte_pci_addr_cmp(pci_addr, &addr))
return devargs;
}
I suspect vmbus is the same, with this uuid stuff.
And others bus need investigation too.
I could try to normalize the devargs names for this lookup.. ?
--
David Marchand
