linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: sedat.dilek@gmail.com
Cc: Kalle Valo <kvalo@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	linux-toolchains@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: Linux 6.3-rc3
Date: Wed, 22 Mar 2023 09:55:57 -0700	[thread overview]
Message-ID: <CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com> (raw)
In-Reply-To: <CA+icZUUYyqhV2HFzVtpi_KjBoYxjk7OB0UBVd2mX6abjmYhDjg@mail.gmail.com>

On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> You have to pass `make LLVM=1` in any case... to `oldconfig` or when
> adding any MAKEFLAGS like -j${number-of-available-cpus}.

I actually think we should look (again) at just making the compiler
choice (and the prefix) be a Kconfig option.

That would simplify *so* many use cases.

It used to be that gcc was "THE compiler" and anything else was just
an odd toy special case, but that's clearly not true any more.

So it would be lovely to make the kernel choice a Kconfig choice - so
you'd set it only at config time, and then after that a kernel build
wouldn't need special flags any more, and you'd never need to play
games with GNUmakefile or anything like that.

Yes, you'd still use environment variables (or make arguments) for
that initial Kconfig, but that's no different from the other
environment variables we already have, like KCONFIG_SEED that kconfig
uses internally, but also things like "$(ARCH)" that we already use
*inside* the Kconfig files themselves.

I really dislike how you have to set ARCH and CROSS_COMPILE etc
externally, and can't just have them *in* the config file.

So when you do cross-compiles, right now you have to do something like

    make ARCH=i386 allmodconfig

to build the .config file, but then you have to *repeat* that
ARCH=i386 when you actually build things:

    make ARCH=i386

because the ARCH choice ends up being in the .config file, but the
makefiles themselves always take it from the environment.

There are good historical reasons for our behavior (and probably a
number of extant practical reasons too), but it's a bit annoying, and
it would be lovely if we could start moving away from this model.

            Linus

  reply	other threads:[~2023-03-22 16:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-19 20:50 Linux 6.3-rc3 Linus Torvalds
2023-03-20  8:21 ` Build regressions/improvements in v6.3-rc3 Geert Uytterhoeven
2023-03-21  5:38   ` Build regressions/improvements in v6.3-rc3 (drm/msm/) Randy Dunlap
2023-03-21  7:34     ` Geert Uytterhoeven
2023-03-21 15:10       ` Randy Dunlap
2023-03-21 15:33         ` Geert Uytterhoeven
2023-03-20 18:05 ` Linux 6.3-rc3 Nathan Chancellor
2023-03-20 18:26   ` Linus Torvalds
2023-03-20 18:49     ` Linus Torvalds
2023-03-20 18:56       ` Nathan Chancellor
2023-03-20 19:05         ` Linus Torvalds
2023-03-20 18:53     ` Nathan Chancellor
2023-03-20 19:22       ` Nathan Chancellor
2023-03-22 12:44       ` Kalle Valo
2023-03-22 16:36         ` Nathan Chancellor
2023-03-22 20:36           ` Nathan Chancellor
2023-03-24 10:54           ` Kalle Valo
2023-03-24 15:11             ` Nathan Chancellor
2023-03-24 15:23               ` Kalle Valo
2023-03-28 19:07                 ` Nathan Chancellor
2023-03-29  8:39                   ` Kalle Valo
2023-03-22 16:40         ` Sedat Dilek
2023-03-22 16:55           ` Linus Torvalds [this message]
2023-03-22 18:17             ` Nick Desaulniers
2023-03-24 17:16             ` Masahiro Yamada
2023-03-27 16:12               ` Jani Nikula
2023-03-27 17:03                 ` Kalle Valo
2023-03-20 20:04     ` Guenter Roeck
2023-03-20 20:30       ` Linus Torvalds
2023-03-20 22:06         ` Nathan Chancellor
2023-03-20 22:48           ` Segher Boessenkool
2023-03-20 23:41           ` Linus Torvalds
2023-03-24  9:41   ` Daniel Vetter
2023-03-20 20:07 ` Guenter Roeck

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='CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=sedat.dilek@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).