Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve tools, clean up old data #69

Merged
merged 9 commits into from Feb 1, 2019

Conversation

andreabolognani
Copy link
Contributor

This series of changes makes it possible to build older kernels using the current script in a simple way, drops all but the most recent kernels since the latter can be used with older images, and performs a few extra smaller cleanups and improvements.

The most recent kernel, kernel-qemu-4.14.79-stretch, added
by commit 36b2f35, is built from the
raspberrypi-kernel_1.20181112-1 tag.

Update build-kernel-qemu accordingly.
When building on machines with more than 4 cores, the current
script would not fully utilize the available resources.

Use `nproc` to dynamically figure out the optimal number of
build jobs for the current machine.
When building old kernels, the .dtb file will not be
generated, resulting in an error when we attempt to copy it.

Solve this by only copying the .dtb file if it actually
exists.
The configuration is not dynamic, so we can simply store it
separately and concatenate it to the configuration file, like
we already do with the networking stuff.
CONFIG_CROSS_COMPILE is the only dynamic part of the
configuration, so we can move the rest to a separate file.

In addition to making the script nicer, this also allows
us to store more than one configuration at a time.
Fished out of commit aeb4259.

Together, these allow to rebuild kernel-qemu-4.4.34-jessie
from the raspberrypi-kernel_1.20161125-1 tag by simply
pointing build-kernel-qemu to it.
Just like the unversioned configuration file is used
unless a more specific version is requested, and in particular
every time the latest kernel is built, it makes sense that
the patch would have the same behavior.

This avoid the awkward situation where, as it happened when
introducing 4.14.79, a new file is introduced despite the
previous version of the patch being applicable as-is.

Going forward, creating a named patch file will only be
necessary when adding support for a new major release of
Raspbian.
Since newer kernels work just fine with older images, at
least within the same Raspbian release, there is no point
in keeping old ones around.

Drop all kernels (along with the corresponding patches and
configuration files) except for the newest one for each
Raspbian release.
@dhruvvyas90 dhruvvyas90 merged commit 84a9cc9 into dhruvvyas90:master Feb 1, 2019
@dhruvvyas90
Copy link
Owner

@andreabolognani : Thanks for the PR. Appreciate your help. 👍

@andreabolognani andreabolognani deleted the cleanup branch February 4, 2019 07:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants