Re: [PATCH] dmaengine: ioat: depends on !UML

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2021-08-25 at 06:31 -0700, Dan Williams wrote:
> On Mon, Aug 9, 2021 at 10:27 AM Johannes Berg <johannes@sipsolutions.net> 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@sipsolutions.net> wrote:
> > > > 
> > > > From: Johannes Berg <johannes.berg@intel.com>
> > > > 
> > > > 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