On Wed, 2021-08-25 at 06:31 -0700, Dan Williams wrote: > 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. > 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
