new kernel ... / meaning of stable-tracking

Andy Green andy at
Tue Sep 23 10:25:53 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| I think the "everything under drivers/mfd/" approach is clearer for
| things like Glamo or PMU, where the subsystem drivers are specialized
| anyway and there are many internal interfaces that are of no use to
| anything else. But I can see the benefits of the other approach as
| well.
| I'll inquire what's best in this case.

Logistically sticking it all in one place is probably marginally better
but it's not a big deal, whatever you hear is best.

|> Werner, how do you feel about guiding and helping Balaji with that?
| Sounds good.


|> It's not simple but it is largely rearrangement and adaptation of known
|> working stuff (so it is testable stage by stage),
| There's one problem, though: this change, while modifying very little
| code, makes the driver completely different from our mainline as far

I think you need to rehearse the process first then find trouble.  I do
this rebasing all the time and there is no problem with it, all of the
rebasing on upstream requires "manual intervention" as you can see by
the number of patches in tracking and 2.6.26 branches beginning
"tracking-", and the many dings on mokopatches directly I just upleveled
so they will compile.  When you get used to it you'll see it's normal
level of stress just like any other changes coming from upstream.

| So I'd suggest to do only the restructuring now, without any other

The restructuring needs doing and proving once, against stable-tracking
/ upstream HEAD.  Doing it against 2.6.24 is pointless for purposes of
getting it upstream, which is the only reason for bothering with this --
we would definitely just leave it alone otherwise since the only things
it gets us are pretty abstract compared to the effort level.  We'll
bring it in to our shipping stable after it's upstream for sure, don't

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list