Re: [PATCH v2] docs: describe how to quickly build a trimmed kernel
From: Thorsten Leemhuis
Date: Wed Feb 15 2023 - 02:45:42 EST
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