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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 25, 2021 at 6:34 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>
> 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*.

It can't compile because the arch dependencies are not stubbed out
like other arch specific helpers. I think this is something to revisit
if / when concepts similar to the "enqcmd" instruction appear on other
archs.



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux