linux-kernel - Re: [PATCH v1] docs: describe how to quickly build Linux

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 1 Feb 2023 14:22:07 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        regressions@...ts.linux.dev
Subject: Re: [PATCH v1] docs: describe how to quickly build Linux

On 01.02.23 13:44, Greg KH wrote:
> On Wed, Feb 01, 2023 at 01:42:29PM +0100, Greg KH wrote:
>> On Wed, Feb 01, 2023 at 12:52:30PM +0100, Thorsten Leemhuis wrote:
>>> Add a text explaining how to quickly build a kernel, as that's something
>>> users will often have to do when they want to report an issue or test
>>> proposed fixes. This is a huge and frightening task for quite a few
>>> users these days, as many rely on pre-compiled kernels and have never
>>> built their own. They find help on quite a few websites explaining the
>>> process in various ways, but those howtos often omit important details
>>> or make things too hard for the 'quickly build just for testing' case
>>> that 'localmodconfig' is really useful for. Hence give users something
>>> at hand to guide them, as that makes it easier for them to help with
>>> testing, debugging, and fixing the kernel.
>>
>> First off, this is great, thanks for doing this.

Thx, feels good to hear.

Bisection is next on my todo list once this matured...

>> One minor comment, to prevent people from "overloading" the
>> git.kernel.org systems:
>>
>>> +.. _sources_sbs:
>>> +
>>> + * Retrieve the sources of the Linux version you intend to build; then change
>>> +   into the directory holding them, as all further commands in this guide are
>>> +   meant to be executed from there.
>>> +
>>> +   If you plan to only build one particular kernel version, download its source
>>> +   archive from https://kernel.org; afterwards extract its content to '~/linux/'
>>> +   and change into the directory created during extraction.
>>> +
>>> +   In most other situations your best choice is to fetch the sources using git::
>>> +
>>> +          git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \
>>> +            ~/linux/sources
>>> +          cd ~/linux/sources/
>>
>> Ideally you should never do a "full clone from scratch" like this, as it
>> takes up loads of server resources.  The "best" way to do this is to
>> download the kernel git bundle, and then pull and resolve the remaining
>> bits.  It's explained, with a script to do the work for you, here:
>>
>> 	https://kernel.org/best-way-to-do-linux-clones-for-your-ci.html
> 
> Oops, here's the full steps involved:
> 	https://www.kernel.org/cloning-linux-from-a-bundle.html
> the first link above has a script that does it all for you, but you
> probably just want to copy the steps at this last link instead.

Great idea, thx for bringing this up -- now that you mention it, I
remember those pages and the script again... :-/

Sadly my "after cloning Linus tree, add the stable tree as remote and
fetch everything" approach would will still create a lot of load. I
could use the script with the stable git repo, as that includes
mainline; but I noticed it sometimes is not fully up2date. At least I
once noticed it was quite a few hours (or maybe even a day?) behind. Is
that normal? I assume you should know.

Anyway: maybe "a little bit behind" isn't something that's much of a
problem for this document.

Ciao, Thorsten