On Wed, 2021-08-25 at 06:31 -0700, Dan Williams wrote:

On Mon, Aug 9, 2021 at 10:27 AM Johannes Berg [off-list ref] wrote:

quoted

On Mon, 2021-08-09 at 10:24 -0700, Dan Williams wrote:

quoted

On Mon, Aug 9, 2021 at 2:25 AM Johannes Berg [off-list ref] wrote:

quoted

From: Johannes Berg <redacted>

Now that UML has PCI support, this driver must depend also on
!UML since it pokes at X86_64 architecture internals that don't
exist on ARCH=um.

Do you really need to disable compilation of the whole driver just
because an arch level helper does not exist on UML builds? Isn't there
already a check for enqcmds on x86_64 to make sure the CPU is
sufficiently feature enabled?

Hmm?

The problem here is that cpuid_eax() and cpuid_ebx() don't even exist on
UML, and that's not really surprising - ARCH=um is after all compiled to
run as a userspace process, not to run on bare metal. I guess
technically we could provide (fake or even sort of real) implementations
of these, but there's very little point?

I don't see why you would ever possibly want to have this driver
compiled on ARCH=um, even if it's compiled for x86-64 "subarch", since
there will be no such device to run against?

See CONFIG_COMPILE_TEST, i.e. even the "depends on X86_64" should be
reconsidered if you ask me.

But CONFIG_COMPILE_TEST is for stuff that can *compile*, just not *work*
independent of the platform - e.g. if I have a driver that compiles
fine, but I know there's never going to be such a PCI device on non-
Intel platforms (happens a lot, after all)

But here it's the other way around - this cannot *compile* even anywhere
other than "X86_64 && !UML", let alone *work*.

johannes