OLPC kernel patches not upstream yet...

[Jeremy Katz]

On Fri, 2008-09-05 at 13:53 -0400, Jim Gettys wrote:
> o The device tree patch; the hold up here is that there are multiple
> implementations of this on Sparc, PPC, and now x86, and no current
> agreement among the guilty on which should become the "standard"
> version. Until/unless the kernel community can come to consensus, this
> seems something not reasonable for a fedora patch.  Andres would like to
> hear from davem in particular on this topic. And we *might* get more
> insight week after next after the kernel summit.

Which is used for what in userspace?  Of course, there's nothing that
would really prevent us from carrying the patch -- it is at least
relatively self-contained, if ugly.  Would have to see what davej thinks
when he's back from SF

> o the touchpad driver for our ALPS touchpad.  We're finally likely to be
> able to come up with something reasonable now that the EC code problem
> has been found, that won't be full of so many one off hack work-arounds.
> As this is a separate driver for unique hardware, this seems like
> something that could go into Fedora without likely headaches, if someone
> wants to keep it synchronized.  But I think the standard touchpad driver
> does at least "work".

I suspect the standard touchpad driver should work, but this also seems
like something which should be pretty easy to upstream in -next :)

> Note that this presumes we're still using at least a OLPC .config file
> going forward as we don't have VESA support for booting in our firmware
> (we use fbdev), so a generic x86 Fedora kernel won't boot.  

Actually, a standard Fedora kernel config boots fine as long as you're
not using an initrd.  Something goes wrong as soon as I throw an initrd
into the mix, though.  Digging through and trying different config
options to try to discern where the problem lies

> We also
> don't want/need to carry the over whelming ton of device drivers, mostly
> for hardware that can never be plugged in, just for space reasons.  

That depends entirely on your target.  Please stop projecting that your
needs and desires are those of everyone.

> It
> would certainly be nice someday if a generic x86 kernel could boot (and
> a standard Fedora desktop spin); I'm not exactly sure what that would
> entail at this point, but for now, this seems like a more speculative
> question and beyond the initial time frame for G1G1.  

It actually seems pretty close from what I was doing on Friday.  Too bad
there's not git-bisect for kernel config options as that would make
things quite a bit faster :-)

> I'm personally
> also by far mos comfortable using a kernel that is as close as possible
> to what we've been testing for our 8.2.0 release at this date, for
> support reasons.

And from a Fedora point of view, that's not something which is at all
comfortable -- it's a kernel rev back, it will need an entirely
different set of security fix requirements, etc. 

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

None of the device-mapper stuff is enabled in the OLPC kernel config, I
suspect due to over-aggressive attempts at space pruning.  But that's
required for running live images since we use dm-snapshot to provide the
semblance of writable area off of read-only media.

And instead of calling new-kernel-pkg and getting the benefits therein,
things are called by hand.  This leads to mkinitrd not being run and so
there's no initrd created for live images.

Jeremy