6:28 a.m.
Hey Chris,
What's the status of the rawhide builds? I haven't seen one for a
while. It would be good to get one based on F11Beta as it would
provide a good point for testing from.
Cheers,
Peter
1:24 p.m.
Hi Peter,
What's the status of the rawhide builds? I haven't seen one
for a
while. It would be good to get one based on F11Beta as it would
provide a good point for testing from.
Yeah! I'm interested in three things at the moment:
* a standard live image for the beta with overlay, for USB and SD.
* an "installed" image for the beta that can be flashed to NAND,
and avoids the live image overhead. Sebastian's been working
on making images like this using ImageCreator.
* an image with the OLPC kernel rather than the Fedora one, so
that people have a way to use suspend/resume with F11. This
one is a little controversial, since our goal is to upstream
everything rather than rely on our custom kernel -- it's clear
that we aren't going to get suspend/resume upstream and back
in time for F11, though, so I'd like to try out an image like
this all the same.
Help very welcome on any of these. :)
- Chris.
--
Chris Ball <cjb(a)laptop.org>
1:29 p.m.
Hi Chris,
> What's the status of the rawhide builds? I haven't
seen one for a
> while. It would be good to get one based on F11Beta as it would
> provide a good point for testing from.
Yeah! I'm interested in three things at the moment:
* a standard live image for the beta with overlay, for USB and SD.
* an "installed" image for the beta that can be flashed to NAND,
and avoids the live image overhead. Sebastian's been working
on making images like this using ImageCreator.
* an image with the OLPC kernel rather than the Fedora one, so
that people have a way to use suspend/resume with F11. This
one is a little controversial, since our goal is to upstream
everything rather than rely on our custom kernel -- it's clear
that we aren't going to get suspend/resume upstream and back
in time for F11, though, so I'd like to try out an image like
this all the same.
I've been meaning to ask about that.... what's the current difference
between the standard Fedora kernel and the OLPC one. I've got a src
rpm of it but haven't had time yet to unpack and investigate. I know
of the dcon driver, and obv something that makes the suspend/resume
work. What's stopping these from being upsteamed? Even if in the case
of the dcon driver its in the staging area of the kernel? At a guess
there's also something for rainbow, but I have no idea what else there
would be.
Help very welcome on any of these. :)
Happy to help, let me know where I can be helpful :-)
Cheers,
Peter
1:37 p.m.
Hi Peter,
I've been meaning to ask about that.... what's the current
difference between the standard Fedora kernel and the OLPC
one.
As far as I know, it's:
* open firmware interface (arch/x86/kernel/ofw.[ch])
* geode GPIO driver (used by DCON and suspend/resume)
* dcon driver (drivers/video/olpc_dcon.[ch])
* suspend/resume code (arch/x86/kernel/olpc_pm.*)
What's stopping these from being upsteamed?
Just the work of submitting them and responding to criticism, which is
hard to find time for; OLPC doesn't employ any kernel hackers at the
moment. Going with staging first does sound like a decent idea.
Thanks,
- Chris.
--
Chris Ball <cjb(a)laptop.org>
1:47 p.m.
Hi Chris,
> I've been meaning to ask about that.... what's the
current
> difference between the standard Fedora kernel and the OLPC
> one.
As far as I know, it's:
* open firmware interface (arch/x86/kernel/ofw.[ch])
* geode GPIO driver (used by DCON and suspend/resume)
* dcon driver (drivers/video/olpc_dcon.[ch])
* suspend/resume code (arch/x86/kernel/olpc_pm.*)
> What's stopping these from being upsteamed?
Just the work of submitting them and responding to criticism, which is
hard to find time for; OLPC doesn't employ any kernel hackers at the
moment. Going with staging first does sound like a decent idea.
By the sound of it getting that into staging would be a good way of
getting it upstreamed, it would allow more feedback and testing
without having to afaict do the full review and also get more eyes on
it which would ultimately help get it mainline with some help from all
of the kernel community. I think that fedora is enabling some features
that are self contained in the staging part of the tree as well which
would also allow us to use the main Fedora kernel.
Peter
2:13 p.m.
On Wednesday, April 01 2009, Peter Robinson said:
> > I've been meaning to ask about that.... what's
the current
> > difference between the standard Fedora kernel and the OLPC
> > one.
>
> As far as I know, it's:
>
> * open firmware interface (arch/x86/kernel/ofw.[ch])
> * geode GPIO driver (used by DCON and suspend/resume)
> * dcon driver (drivers/video/olpc_dcon.[ch])
> * suspend/resume code (arch/x86/kernel/olpc_pm.*)
>
> > What's stopping these from being upsteamed?
>
> Just the work of submitting them and responding to criticism, which is
> hard to find time for; OLPC doesn't employ any kernel hackers at the
> moment. Going with staging first does sound like a decent idea.
By the sound of it getting that into staging would be a good way of
getting it upstreamed, it would allow more feedback and testing
without having to afaict do the full review and also get more eyes on
it which would ultimately help get it mainline with some help from all
of the kernel community. I think that fedora is enabling some features
that are self contained in the staging part of the tree as well which
would also allow us to use the main Fedora kernel.
Fedora isn't enabling things from staging because they tend to be things
which are poorly maintained and don't have a real path to upstream.
Also, most of the pieces in question aren't drivers and thus couldn't go
into staging anyway. And the one piece that is a driver (the dcon) ends
up depending on some of the pieces which aren't.
Jeremy
2:18 p.m.
> > * open firmware interface (arch/x86/kernel/ofw.[ch])
> > * geode GPIO driver (used by DCON and suspend/resume)
> > * dcon driver (drivers/video/olpc_dcon.[ch])
> > * suspend/resume code (arch/x86/kernel/olpc_pm.*)
> >
> > > What's stopping these from being upsteamed?
> >
> > Just the work of submitting them and responding to criticism, which is
> > hard to find time for; OLPC doesn't employ any kernel hackers at the
> > moment. Going with staging first does sound like a decent idea.
>
> By the sound of it getting that into staging would be a good way of
> getting it upstreamed, it would allow more feedback and testing
> without having to afaict do the full review and also get more eyes on
> it which would ultimately help get it mainline with some help from all
> of the kernel community. I think that fedora is enabling some features
> that are self contained in the staging part of the tree as well which
> would also allow us to use the main Fedora kernel.
Fedora isn't enabling things from staging because they tend to be things
which are poorly maintained and don't have a real path to upstream.
Also, most of the pieces in question aren't drivers and thus couldn't go
into staging anyway. And the one piece that is a driver (the dcon) ends
up depending on some of the pieces which aren't.
OK, wasn't aware staging was such a mess. Do you have any other
suggestions as to the best way to get this stuff upstream? I'm not a
kernel developer so its not something I see that I can take on
effectively.
Peter
2:11 p.m.
On Wednesday, April 01 2009, Chris Ball said:
> What's stopping these from being upsteamed?
Just the work of submitting them and responding to criticism, which is
hard to find time for; OLPC doesn't employ any kernel hackers at the
moment. Going with staging first does sound like a decent idea.
staging is essentially a giant dumping ground of abandonware -- if you're
going to put in the effort, please do it right. The whole "what's the
fastest point from A->B" is why we're *in* this mess where there's a
huge pile of not-upstreamed kernel code to begin with
Jeremy
2:17 p.m.
chris wrote:
Hi Peter,
> I've been meaning to ask about that.... what's the current
> difference between the standard Fedora kernel and the OLPC
> one.
As far as I know, it's:
* open firmware interface (arch/x86/kernel/ofw.[ch])
* geode GPIO driver (used by DCON and suspend/resume)
* dcon driver (drivers/video/olpc_dcon.[ch])
* suspend/resume code (arch/x86/kernel/olpc_pm.*)
also parts of the HGPK touchpad: drivers/input/mouse/olpc.c
i believe it's been upstreamed, but there are outstanding patches that
need reworking before resubmission.
paul
=---------------------
paul fox, pgf(a)laptop.org
8:13 p.m.
Scott Douglass in "using the stock OLPC kernel in F11/Rawhide"
mentioned sound also:
It is possible to use the stock OLPC kernel which includes power
management, DCON and working audio drivers (at the least) with the
F11/Rawhide images that CJB is generating.
Chris Ball wrote:
* open firmware interface (arch/x86/kernel/ofw.[ch])
* geode GPIO driver (used by DCON and suspend/resume)
* dcon driver (drivers/video/olpc_dcon.[ch])
* suspend/resume code (arch/x86/kernel/olpc_pm.*)
pgf added
also parts of the HGPK touchpad: drivers/input/mouse/olpc.c
i believe it's been upstreamed, but there are outstanding patches that
need reworking before resubmission.
(also
I added a these in a kernel section to
http://wiki.laptop.org/go/Rawhide-XO#Known_issues
5545
days inactive
5546
days old
9 comments
5 participants
participants (5)
-
Chris Ball -
Jeremy Katz -
Paul Fox -
Peter Robinson -
S Page