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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=whXbDkQQUjF1mLPoMkhbJpv1jQtsazWwDGMF9vw1tx+vA@mail.gmail.com>
Date:   Fri, 12 Aug 2022 10:27:04 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] VFIO updates for v6.0-rc1 (part 2)

On Fri, Aug 12, 2022 at 9:58 AM Jason Gunthorpe <jgg@...dia.com> 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

View attachment "patch.diff" of type "text/x-patch" (567 bytes)