linux-kernel - Re: [GIT PULL] x86/entry for 7.0-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjOsk8ddzcCE0NvTQ4+CEznBFuB99DoyM4r1baavEyw=A@mail.gmail.com>
Date: Wed, 11 Feb 2026 09:05:58 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] x86/entry for 7.0-rc1

On Wed, 11 Feb 2026 at 08:30, H. Peter Anvin <hpa@...or.com> wrote:
>
> I don't know if it is "wrong", but I have a build setup with canned
> configurations that build into separate directories, while keeping the
> sources the same so I can try to see if one tweak changes anything in
> any of those configurations.
>
> The second thing is that it makes it *very* easy to separate source
> from generated...

So I personally find the build trees convenient for automation or for
just building other peoples projects, but annoying for when I do
actual development.

It's easy for automation because there you care more about the build
tree than the source tree, and the build has an unambiguous "this is
where the sources are", and it's all scripted anyway.

So if you do automation - like building N different targets for
various different configurations - you love build trees, because it's
very natural, and it makes what you care about - the build - the
central part.

Same goes for "I build somebody else's project" where there may not be
different configurations, but the thing you care about is the end
result, not the source tree.

So then doing the standard (for cmake) dance of

   mkdir build && cd build && cmake ..

is pretty simple. It's just a special case of the "automation" case
where having just one special build location avoids the "where to put
the build" question.

But as a developer, I used to just detest them.

Going somewhere else to test-build something is just a supremely
annoying extra step to me. Yes, you can use multiple terminals, or an
IDE - or aliases or other abstractions - that deals with the whole
"build here, work there" thing.

But I have always felt that if I care primarily about a source tree,
I'd much rather just have the build right there, and not have to care
about the distinction.

I often actually look at the build results. Not the object files, no.
But I do things like

   make xyz/file.s

*ALL* the time when developing, and I just don't want to have to treat
the "this was what I just generated" and "this was what I generated it
from" as something very different.

Admittedly, these days I don't do much actual development, so I guess
I wouldn't care.

Which reminds me that I need to go back to merging...

              Linus