On Mon, Aug 9, 2021 at 10:27 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2021-08-09 at 10:24 -0700, Dan Williams wrote: > > On Mon, Aug 9, 2021 at 2:25 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > > > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > > > > > 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.
