On Thu, 2011-03-31 at 16:56 +0100, Chris Jones wrote:
> I've been working on this for days now and I still don't know quite what 

> - check out head of menuconfig2 branch from svn

Surely the Balloon kernel tree is not kept in SVN? Also, the fact you
are maintaining kernel patches in quilt sounds quite dodgy to me too.

The only sane way to manage kernel branches is in git, possibly
(although not necessarily) using stgit to manage patch stacks on top of
that. (stgit has its pros and cons, but basically works like quilt).


I guess the issue here is that not all the Balloon developers are
seasoned kernel hackers, so this won't come easy to them.

I wouldn't call myself one either (although I've done some driver work
on the Intel graphics stack before now). This is my excuse for not
providing a better opinion of _exactly_ how things should be done ;)


> 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

I think you need to push the patches into place before you edit their
contents.

>    - 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.

It might make sense to make a new quilt patch for those temporary
changes - so you can pop them on and off easily.

>    - 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?

Is that menuconfig2's job? Or do you have to do it manually I wonder?

Slightly off at a tangent - but you can ease the pain of rebuilds by
installing "ccache" if you haven't already got it. This makes rebuilds
of already cached compilations really fast. (Often in cases where make
cannot assume a file does not need to be rebuilt).

I've no idea how to setup ccache for a cross compile build though -
sorry.

> 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.

I think if your patch touches Kconfig stuff, it will automatically want
to check up on your config. "make oldconfig" is something I use quite
often when building PC kernels.

> 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:

Sounds like stgit would be useful to you guys.

> 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?

git diff ?

(Or is your kernel tree not a git checkout?)

> 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.

I have to confess feeling lost with a lot of automated kernel build
stuff. I can just about build a custom Ubuntu kernel, but I don't grok
all the custom configurations stuff for multiple targets.

Once I have a known working .config file, I save that - use it all the
time, and just build using "make", "make modules_install" and "make
install" from the kernel tree. That might be more a PC kernel workflow -
and it could well have been customised by Ubuntu, as I use their git
repositories for my kernel.

Good luck, and best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)