kernel config & git -

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy,
|
| You are forgetting one thing - the whole beauty of open source is you
| are free to do whatever you want with the thing. If users want to create

Forget?

|> I also hope users decide to do random things not necessarily based on
|> what we decide we like (good example is the fully working Debian that

I didn't forget anything about user freedom, in fact I am rather hoping
the users will come and save us from ourselves in some respects.  And I
know I am avant-garde about it in Openmoko to the point of making
trouble for myself.

| The relationship between the kernel and application layer of the OM
| phone should be minimized. The job of the kernel is to supply all the
| necessary hardware support to the application layer with little

Wah no offence but primary job of the kernel is to work.  We have our
hands full with that, these various helpful dogmata grinding the kernel
under one heel or another are not useful.

Case by case stuff can need to live in hardware, FIQ, ISR, kernel guts,
kernel driver, kernel thread, daemon, libs, commandline app, X driver,
X, toolkit, gui app and the boundaries are fluid to allow us to optimize
to one goal or another.  Stuff can conceivably live in not just one but
sometimes ANY of the layers usefully, to meet different goals.  So
decisions must be made with a "system level view" of what we try to
achieve and why, not by consulting an org chart of whose floor the
kernel gets to lick today.

| In the long run, I think you are heading in the right direction by
| basing your work off a main kernel as opposed to keeping an entire

Of course, it would be insane.

| version. If I understood you right from a previous email the mechanism
| should end up looking like:
|
| git clone mainline-kernel
| git pull git.openmoko.org/OM-changes
|
| Was this what you had in mind? There could then be branches for a number
| of specific versions of linux kernels or the tracking branch. These
| branches could in turn be based on some other branch to assist in
| merging necessary fixes to all the appropriate branches.

That's not directly the intention, since we pull mainline ourselves as
"master" in git.  So you don't need to go around Gentoo style pulling
from different repos.  However the structure in git is carefully layered
do we don't shoot ourselves in the foot, as a side-effect you have the
flexibility to pretty much do what you like.  I think it is already what
you're interested in.

Generally for the different tree sets it looks the same:

master -> mokopatches -> stable -> andy -> debug

each one is based on top of the predecessors.  I just exposed half of
the 2.6.26 tree earlier and that is

2.6.26 -> mokopatches-2.6.26 -> stable-2.6.26

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiMnCAACgkQOjLpvpq7dMpgQwCdH7Mi/G2d0ZdhrxriLvaEJBSz
Ct4AnRD4PIN7R3qbWbwQzXajsM0HeYmm
=82YE
-----END PGP SIGNATURE-----