How to bisect suse kernel efficiently?

[Matwey V. Kornilov]

Hi,

I've just found the beaglebone black had been broken between 3.16.3 and
3.16.4 and not booted anymore.

Until then, I just utilized OBS and osc build --local to build the
kernel for arm architecture with needed patches/configs. But now I
wonder whether there is more effective way to avoid rebuilds?
Usually, changes affect only couple of modules, but building with OBS
requires to wait until whole kernel is rebuilt.

If there is a way to pack the modules into the RPM after they were built
with conventional make?
Since my target is tiny arm board I need a simple way to deploy the
kernel on it, and I think RPM is perfectly right one.
But RPM building force me to rebuild everything from scratch every time.

[David Sterba]

Post by Matwey V. Kornilov
Until then, I just utilized OBS and osc build --local to build the
kernel for arm architecture with needed patches/configs. But now I
wonder whether there is more effective way to avoid rebuilds?
Usually, changes affect only couple of modules, but building with OBS
requires to wait until whole kernel is rebuilt.

There are ways to speed up the process.

Use --ccache for build, this will keep all the built objects and just
copy them instead of compiling, if you use --jobs 32 or something high
like that, the parallelism should help as well.

If you can identify which patches probably touched the driver or
functionatlity it uses, look at the patches between .3 and .4 in

git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

and run only a few iterations instead of full bisection of the whole
patchset.

You can also reuse the OBS chroot environment and revert/apply the
patches directly to the sources and then run the kernel build manually
(the exact command is in the log), then copy the resulting .ko into your
system and try it.

Depends if the ccache approach is faster than the manual one.

[Matwey V. Kornilov]

Post by David Sterba
Use --ccache for build, this will keep all the built objects and just
copy them instead of compiling, if you use --jobs 32 or something high
like that, the parallelism should help as well.

Could you please explain where ccache caches it cache. I suppose inside
the build_root. Will --clean option purge it?

[David Sterba]

Post by Matwey V. Kornilov

Post by David Sterba
Use --ccache for build, this will keep all the built objects and just
copy them instead of compiling, if you use --jobs 32 or something high
like that, the parallelism should help as well.

Could you please explain where ccache caches it cache. I suppose inside
the build_root. Will --clean option purge it?

Yes, the cache is kep in the build root. Manual page says about

--clean Delete old build root before initializing it

so no, the cache is gone afterwards.

[Andreas Schwab]

Post by David Sterba

Post by Matwey V. Kornilov

Post by David Sterba
Use --ccache for build, this will keep all the built objects and just
copy them instead of compiling, if you use --jobs 32 or something high
like that, the parallelism should help as well.

Could you please explain where ccache caches it cache. I suppose inside
the build_root. Will --clean option purge it?

Yes, the cache is kep in the build root. Manual page says about
--clean Delete old build root before initializing it
so no, the cache is gone afterwards.

No, it isn't. --clean doesn't remove dot files in the root directory,
so /.ccache is kept.

Andreas.