OLPC kernel patches not upstream yet...

[Jim Gettys]

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.

I'm mostly concerned about the size of /lib/modules/xxx/

It's 38 megabytes compressed .gz, without pruning, on my conventional
laptop.

Much finer grained packaging of the kernel is what's actually in order;
I just think that isn't likely to happen quickly enough.  We certainly
did lots of this for the iPAQ in Familiar, where we had a total of 16 or
32 meg of flash for *everything*.

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

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


-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child