OLPC kernel patches not upstream yet...

[Jeremy Katz]

On Sun, 2008-09-07 at 22:15 -0400, Jim Gettys wrote:
> On Sun, 2008-09-07 at 21:45 -0400, Jeremy Katz wrote: 
> > > 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.
> 
> Heh.  You are used to big hard disks......  Or at least a CD, where you
> are allowed to fill it and have other places to store files.
>
> Would that flash were free, or at least 4 times cheaper.

That's just my point, though.  You have decided that the only thing that
makes sense for Fedora on the XO is via the internal jffs2.  I'm less
convinced that that is the path which makes the most sense

> > > 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. 
> 
> I believe strongly for this initial F10 G1G1 release we should go with a
> kernel as close as possible to what we've been testing for OLPC's 8.2.0
> release rather than the Fedora F10 kernel.
> 
> This can/should be revisited once there is some time and a full Fedora
> release cycle to test it on significant numbers of rawhide users.  
> 
> The problem is that at this date, starting late, with no significant
> number of users, the stock fedora kernel won't have enough soak time,
> even if we could magically make all patches appear in rawhide tomorrow.
> Nor do we have the time and hackers and test machines running a stock
> Fedora kernel to chase any bugs right now on top of the release we're
> getting out the door.
> 
> *This* is the issue.  Testing and mitigating risk.  For F11, sure....
> The equation will be very different, given another 6 months, and a
> chance at a testing base of significant size.

There's an equivalent set of risks on the other side of the coin with
using the Fedora userspace with a completely different kernel than
what's being used for the rest of the testing, integratation, etc.  This
*is* important and it does tickle all kinds of "odd" bugs based on past
experience.  And it's exactly the sort of thing that we've finally
gotten rid of with Xen with the very explicit statement of _not_
allowing it in something called Fedora in the future.  

And the need for being able to follow the security updates is very real

> > > 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.
> 
> I'm sure from the sound of it Andres would be happy to see an updated
> spec file he can use in our 8.2.1 release...

... the best way to get you an updated spec file is to switch so that
your kernel is being built out of the same sources, with the same spec,
etc and maybe just with a different config rather than off doing its own
thing

Jeremy