Date:   Wed, 15 Feb 2023 08:45:31 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Bagas Sanjaya <bagasdotme@...il.com>,
        Jonathan Corbet <corbet@....net>
Cc:     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, Greg KH <gregkh@...uxfoundation.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: [PATCH v2] docs: describe how to quickly build a trimmed kernel

Thx for your feedback, much appreciated.

On 15.02.23 04:51, Bagas Sanjaya wrote:
> On Tue, Feb 14, 2023 at 07:58:09PM +0100, Thorsten Leemhuis wrote:
>> +   Execute the following command to retrieve a fresh mainline codebase::
>> +
>> +     git clone --no-checkput --depth 1 -b master \
>> +       https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git \
>> +       ~/linux/sources/
>> +     cd ~/linux/sources/
>> +
>> +   If you want to access recent mainline releases and pre-releases, deepen you
>> +   clone's history to the oldest version you are interested in::
>> +
>> +     git fetch --shallow-exclude=v6.0
> 
> For me, another way is to use `git fetch --shallow-since="<some-date>"

Well, that's described in the reference section as an alternative. Did
you miss that, or do you think that --shallow-since should be used by
default for some reasons? If so: which?

> && git repack -a -d`.

`git repack -d` (also mentioned in the reference section of the
submitted text) seems to suffice in my (limited!) testing.

> This requires knowing version release date.

Which is why I (for now!) settled on using "--shallow-exclude=" by default.

> If
> you want that version, the date used should be one or two days before
> that version's release date. Repacking is important!
> 
> Nevertheless, you need to go to Git ML and ask why repacking is required
> in that case (I have tried searching threads there, but inconclusive).

Yeah, I also wonder why the repacking is needed, but chose to not
investigate... Maybe I should have, but writing that text already took
quite some time and effort. :-/

>> +The make target olddefconfig and the ``yes "" |`` used when utilizing
>> +localmodconfig will set any undefined build options to their default value. This
>> +among others will disable many kernel features that were introduced after your
>> +base kernel was released.
>> +
>> +If you want to set these configurations options manually, use ``oldconfig``
>> +instead of ``olddefconfig`` or omit the ``yes "" |`` when utilizing
>> +localmodconfig. Then for each undefined configuration option you will be asked
>> +how to proceed. In case you are unsure what to answer, simply hit 'enter' to
>> +apply the default value.
> 
> olddefconfig and `yes "" | make localmodconfig` can produce different
> config, since the default value for new config symbols may not be Y.
> Often, for new drivers, the default is N.

Are you sure? A `yes ""` doesn't set everything unset to Y, it afaics
just sends an "enter" -- and then the default should be used (as
explained in the documents reference section). Shouldn't the end result
thus be similar? Or am I missing something?

>> + * Remove a stale reference to a certificate file that would cause your build to
>> +   fail::
>> +
>> +    ./scripts/config --file ~/linux/build/.config --set-str SYSTEM_TRUSTED_KEYS ''
>> +
>> +   Alternatively, download the needed certificate and make that configuration
>> +   option point to it, as `the Debian handbook explains in more detail
>> +   <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_ .
>> +
> 
> Another way is to generate the certificate yourself (see
> Documentation/admin-guide/module-signing.rst for the instructions).

Ohh, thx, yeah, I guess I should refer to that file here and in another
place, even if it requires a lot more from the reader. :-/

Ciao, Thorsten

Powered by blists - more mailing lists