Re: [GIT PULL] VFIO updates for v6.0-rc1 (part 2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 12, 2022 at 9:58 AM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
>
> I think this is partly a historical artifact because each of the files
> in the directory are compiling to actual kernel modules so the file
> name has to have vfio_ in it to fit into the global module namespace.
>
> Now, there is no reason I can see for all these files to be different
> modules, but that is how it is, and because we have some module
> parameters changing it is API breaking..

Oh, the module name issue is absolutely real.

But we actually have good tools for that in the kernel build system,
because we've had that issue for so long, and because it's not at all
uncommon that one single kernel module needs to be built up from
multiple different object files.

I guess it does require an extra lines in the Makefile. Maybe we could
improve on that, but that extra line does end up having real
advantages in that it makes for a lot of flexibility (see below).

Attached is a truly *stupid* patch just to show the concept. I
literally just picked one vfio file at random to convert. The point
being that this approach

 (a) makes it very easy to have the file naming you like

 (b) makes it *very* easy to have common helper libraries that get
linked into the modules

 (c) also means that it's now basically trivial to split any of these
drivers into multiple files, exactly because the file name isn't tied
to the module name

where that extra line is exactly what makes (b) and (c) so trivial.

Now, don't get me wrong: this patch is *not* meant to be a "please do
this". If people really like the current odd file naming policy, it's
really not a lot of skin off my nose.

So the attached patch is literally meant to be a "look, if you want to
do this, it's really this simple".

And you can easily do it one driver at a time, possibly when  you have
a "oops, this one driver is getting a bit large, so I'd like to split
it up".

Also, it should go without mention that I've not actually *tested*
this patch. I did do a full build, and that full build results in a
vfio_iommu_type1.ko module as expected, but there might be something I
overlooked.

There's also some build overhead from the indirection, but hey, what
else is new. Our Makefiles are actually quite powerful, but they do
make 'GNU make' spend a *lot* of time doing various string tricks.

                    Linus
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 1a32357592e3..41ed528c7587 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -3,6 +3,8 @@ vfio_virqfd-y := virqfd.o
 
 vfio-y += vfio_main.o
 
+vfio_iommu_type1-y = iommu_type1.o
+
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/iommu_type1.c
similarity index 100%
rename from drivers/vfio/vfio_iommu_type1.c
rename to drivers/vfio/iommu_type1.c

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux