[Balloon] Kernel hacking workflow

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Chris Jones
Date:  
To: Balloon
Subject: [Balloon] Kernel hacking workflow
I've been working on this for days now and I still don't know quite what
I'm doing or why I have so much grief from the build system. I'd like to
learn how, and then I'd like to write it down in the Wiki.

What I'm doing should be pretty typical for a Balloon user and
developer: working on adding support for different hardware in to the
kernel. This is what Balloon is for, and a major part of its value. We
need to make it easy, and tell people how to do it.

Here's what I'm doing at the moment:
- check out head of menuconfig2 branch from svn
- make menuconfig
- build everything
- make kernel-menuconfig, choose the things which are important to me
(in this case, various sound drivers, USB RNDIS old-kernel hack)
- make
- check that the basic setup works on the board.

So far so good, all credit to the team who've put together the build system.

Now I want to change things.

I want to, in this case, add source for a couple of new kernel modules
(/sound/soc/pxa/balloon3-tt.c and /sound/soc/codecs/ttdsp.c), the
associated Kconfig adjustments, and probably modify
/arch/arm/mach-pxa/balloon3.c and include/mach/balloon3.h for some
low-level startup support.

Nick B has done most of this, but I'd like to understand it better.

We have a patch, balloon3-i2s.patch in this case, which can be managed
by quilt. Fine.

How do I decide where to put this patch in the series? How do I find the
right place in /package/kernel? Which series file should I modify?

My workflow goes something like this:
- build kernel (make at menuconfig2 top level)
- download to board, test, discover bugs as expected
- in build tree:
- quilt pop balloon3-i2s
- edit various files. Some of these are in the patch, others won't
be. For example, I've put debug code in /arch/arm/mach-pxa/mfp-pxa2xx.c
which I don't expect to become part of the patch but makes my
development job easier.
- quilt refresh
- back at menuconfig2 top level, make again.

What happens now seems to be unpredictable. My kernel .config tends to
get forgotten, which wastes a lot of time. I have to copy that into
/package/kernel/.../balloon3config-whatever..., don't I?

It's quite common that the kernel just won't build. For example, at this
very moment, if I try to make, it dies with 'balloon3_gpio_vbus
undeclared'. It seems not to have reapplied the patch series. Why not?

If I quilt push -a, then try make again, it starts asking me config
questions. Why? Why? Note that I'm making in menuconfig2, not /build/kernel.

To get to this state, all I did was move some edits from one patch to
another. I'd patched balloon3.c in balloon3-i2s.patch, which is bad news
because that file is already patched in balloon3.patch. So I decide to
fix that. No problem:

- quilt pop balloon3-i2s
- copy the changes out of the files into a blank buffer
- quilt remove /arch/arm/mach-pxa/balloon3.c
- quilt refresh
- quilt pop balloon3
- paste changes into /arch/arm/mach-pxa/balloon3.c
- quilt refresh

But now the kernel won't build, see above.

I don't want to throw my source tree away and start again because it's
got changes in which aren't part of a patch, and I don't want to spend
time tracking them down and recording them. I shouldn't have to do this,
surely?

What's the *right* way to do this? Tell me, and I'll write it down
somewhere that everyone can see.

This sort of documentation is essential. We have a complex build system
and no documentation on how it works, so anything other than a
straightforward distro build feels dangerous. I want to help change that.

Chris
--
Chris Jones -
Martin-Jones Technology Ltd c/o Element Energy Ltd
Twenty Station Road, Cambridge, CB1 2JD, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908