3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-22 17:55:57 +01:00
Code Issues Releases Wiki Activity

buildroot: use our fork for rpath

Browse Source
This commit is contained in:
Ciro Santilli
2018-06-10 10:15:35 +01:00
parent c375d58e44
commit 007e4114a6
5 changed files with 13 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.gitmodules vendored
View File

@@ -1,6 +1,6 @@
[submodule "buildroot"]
path = buildroot
url = https://github.com/buildroot/buildroot
url = https://github.com/cirosantilli/buildroot
ignore = dirty
[submodule "qemu"]
path = qemu

24
README.adoc
View File

@@ -6616,23 +6616,15 @@ One way to overcome this problem is to mount benchmarks from host instead of add
Buildroot is not designed for large root filesystem images, and the rebuild becomes very slow when we add a large package to it.
This is due mainly to the `pkg-generic` `GLOBAL_INSTRUMENTATION_HOOKS` sanitation which go over the entire tree doing complex operations... I no like, in particular `check_bin_arch` and `check_host_rpath`, which get stuck for a long time on the message:
This is due mainly to the `pkg-generic` `GLOBAL_INSTRUMENTATION_HOOKS` sanitation which go over the entire tree doing complex operations... I no like, in particular `check_bin_arch` and `check_host_rpath`
We have applied link:https://github.com/cirosantilli/buildroot/commit/983fe7910a73923a4331e7d576a1e93841d53812[983fe7910a73923a4331e7d576a1e93841d53812] to out Buildroot fork which removes part of the pain by not running:
....
>>> Sanitizing RPATH in target tree
....
The pause is followed by:
....
out/arm/buildroot/build/<pkg>/.stamp_target_installed
....
so which shows that the whole delay is inside our install itself.
I put an `echo f` in `check_bin_arch`, and it just loops forever, does not stop on a particular package.
Ignored / declined patch at: http://lists.busybox.net/pipermail/buildroot/2018-May/220662.html I might just fork Buildroot on the submodule if this keeps annoying me.
which contributed to a large part of the slowness.
=== Report upstream bugs
@@ -7087,9 +7079,13 @@ The action seems to be happening at: `hw/arm/virt.c`.
***** `out/common/gem5/<variant>/m5out`
***** `out/common/gem5/<variant>/system`
:leveloffset: +3
==== buildroot_patches
include::buildroot_patches/README.adoc[]
Every `.patch` file in this directory gets applied to Buildroot before anything else is done.
This directory has been made kind of useless when we decided to use our own Buildroot fork, but we've kept the functionality just in case we someday go back to upstream Buildroot.
:leveloffset: +3
include::global_patch_dir/README.adoc[]

2
buildroot

Submodule buildroot updated: f3d114a1ef...bc60382b8f

10
buildroot_patches/README.adoc
View File

@@ -1,9 +1 @@
= buildroot_patches
Every `.patch` file in this directory gets applied to Buildroot before anything else is done.
Ideally, this directory should be empty, and we should use only built-in Buildroot configuration mechanisms.
But alas, life is sometimes not ideal.
We will use those patches only for things which could / have already been upstreamed. The patches will then be removed once we are able to rebase. Educational patches that we might want to do on QEMU will be done by forking the QEMU repo on our submodule. The difference is that it is a bit easier to remove the patches after upstreaming than to squash them out on rebase.
https://github.com/cirosantilli/linux-kernel-module-cheat#buildroot_patches

12
buildroot_patches/qemu-rm-with-system-pixman.patch
View File

@@ -1,12 +0,0 @@
diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
index f02df8bcc1..3b139bafa9 100644
--- a/package/qemu/qemu.mk
+++ b/package/qemu/qemu.mk
@@ -224,7 +224,6 @@ define QEMU_CONFIGURE_CMDS
./configure \
--prefix=/usr \
--cross-prefix=$(TARGET_CROSS) \
- --with-system-pixman \
--audio-drv-list= \
--enable-kvm \
--enable-attr \