OLPC kernel patches not upstream yet...

[Jeremy Katz]

On Mon, 2008-09-08 at 18:17 +0000, Deepak Saxena wrote:
> Sorry for the delayed response, have been slowly catching up to email
> after vacation.

No worries -- vacations are good :)

> > Jeremy also noted a bit of version skew between the fedora and olpc rpm
> > spec file that could/should be resolved; there were a couple of trivial
> > config file changes that enables something build from the OLPC kernel to
> > be used in a Fedora spin (the squashfs patch, which all distros carry
> > but isn't in kernel.org, and one other item that I forget).
> 
> I would love to see us move to the new spec file format as it seems
> much easier to understand and maintain.

That was the idea, so glad that people think so

> > Andres, Deepak, did I miss anything?
> 
> I just did a git-diff v2.6.25.15..olpc-2.6/testing and the following
> minor things also stand out:
> 
> - SD timeout patch. I think there's a cleaner way to do this with
>   quirks that Pierre introduced, I need to to revisit this.

Yeah, this looked to me like it would be fine with what's currently
upstream in 2.6.27-git

> - Some minor changes to the AT keyboard driver that should be pulled
>   into a separate file.

This one I had big question marks by as to what the intent was

> - The Libertas driver is in my opinion somewhat of a mess. We've got
>   bits from upstream, bits from our 2.6.22 tree that never got pushed
>   upstream. All of this needs to be consolidated and pushed upstream.

I thought that upstream here had been cleaned up and was actually acting
sane now.  If not, then some hammering might be in order.

> Looking ahead at the 9.x releases, we will be throwing LogFS and YAFFS2
> into the kernel to do some analysis on alternatives to JFFS2 and we will
> possibly use one of those as we move forward.

And there's also now ubifs upstream

> Jeremy, how do we deal with the fact that OLPC is using Git for development 
> while Fedora/RHEL are based on CVS + quilt patches? Simplest solution is
> to just generate one big patch for the OLPC kernel that we drop on top of 
> the Fedora kernel but that looses a lot of history. Generating one patch
> per commit is doable if we cleanup our history so that we don't have
> complex merges.

Either an OLPC patch or trying to keep the OLPC patches each maintained
as topic branches that then got brought together should work.  Roland's
utrace stuff is currently maintained in a git repo and just has the big
patch drop effect.  But the goal is of course continuing to decrease the
size until it's not that relevant to worry about.  While there will
always be things queued for -next, the given release kernel should
hopefully be able to be "good enough" and then n+1 is just better.

> Do you happen to be in Portland next week for Kernel Summit/Plumber's Conf?
> Andres will be here and it'd be great if we could meet f2f to talk about this.

Sadly, I won't.

Jeremy