On Thu, 1 Jun 2023 17:48:27 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
> On Thu, Jun 01, 2023 at 02:42:38PM -0600, Alex Williamson wrote:
> > On Mon, 29 May 2023 14:47:59 -0300
> > > +config VFIO_PCI_CORE
> > > + tristate "VFIO support for PCI devices"
> > > + select VFIO_VIRQFD
> > > + select IRQ_BYPASS_MANAGER
> > > + help
> > > + Base support for VFIO drivers that support PCI devices. At least one
> > > + of the implementation drivers must be selected.
> >
> > As enforced by what?
>
> Doesn't need to be enforced. Probably should have said "should"
>
> > This is just adding one more layer of dependencies in order to select
> > the actual endpoint driver that is actually what anyone cares about.
>
> This is making the kconfig more logical and the menu structure better
> organized. We eliminate the need for the drivers to set special
> depends because the if covers them all.
We can create a menu with a dummy config option, ex:
config VFIO_PCI_DRIVERS
bool "VFIO support for PCI devices"
default y
if VFIO_PCI_DRIVERS
...
So the menu organization itself isn't sufficient for me to make
VFIO_PCI_CORE to root of that menu.
The flip side of requiring drivers to set a "special depends" is that
it's possible we might have a PCI variant driver that doesn't use
VFIO_PCI_CORE. It would be a hard sell, but it's possible. It also
shouldn't be terribly subtle to the existing variant drivers relying on
vfio-pci-core that this dependency exists.
Allowing VFIO_PCI_CORE without building an in-kernel module that
depends on it seals the deal for me that this is the wrong approach
though.
> > I don't see why we wouldn't just make each of the variant drivers
> > select VFIO_PCI_CORE. Thanks,
>
> It can be done, but it seems more fragile.
How so? Thanks,
Alex
