mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Johannes Berg' <johannes@sipsolutions.net>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Johannes Berg <johannes.berg@intel.com>
Subject: RE: [PATCH] um: don't use CONFIG_X86_{32,64} symbols on x86
Date: Fri, 3 Sep 2021 08:27:24 +0000	[thread overview]
Message-ID: <f177f8b287f14c93b04542d7ab4a8dfd@AcuMS.aculab.com> (raw)
In-Reply-To: <20210902102750.1ddfef4c1915.Icb5c49998c55b87c8584d46894c01b114ae2e661@changeid>

From: Johannes Berg
> Sent: 02 September 2021 09:28
> 
> The CONFIG_X86_32 and CONFIG_X86_64 symbols are used by
> both "real" x86 architecture builds and ARCH=um today.
> However, clearly most people and places in the code are
> treating it as the architecture Kconfig (technically
> that's just CONFIG_X86) and use it to indicate that the
> architecture is X86 in 32- or 64-bit flavour.
> 
> This has caused a fair amount of issues in the past,
> for example drivers not building because use x86 macros
> or similar under CONFIG_X86_{32,64} ifdef, and then we
> find build reports and add "!UML" to their Kconfig etc.
> 
> However, this is error-prone and a kind of whack-a-mole
> game, even with the build bots reporting things.

I suspect you've just changed the 'mole'.

You've now got lots of lines like:

#if defined(CONFIG_X86_64) || defined(CONFIG_X86_64_UML)

Missing off the UML define is going to cause the 32bit code
to get compiled by mistake - which is likely to be more
confusing that the places where you need to do special 'stuff'
for UML.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2021-09-03  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02  8:28 Johannes Berg
2021-09-03  8:27 ` David Laight [this message]
2021-09-03  8:40   ` Johannes Berg
2021-09-03 10:05     ` Anton Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f177f8b287f14c93b04542d7ab4a8dfd@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®