Upstreaming (offer to help)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Upstreaming (offer to help)

Sveinung Kvilhaugsvik
Hello

What is holding the drivers for the Freerunner back from being merged
upstream? Can I do something to help? Following is a suggestion for
what I could do. (Please be aware that English is not my native
language. So if something is unclear, impossible to understand, easy
to misunderstand or written in an insulting tone please ask me to
clarify)

First some background on my thinking. I think the drivers that still
are missing can be divided in four classes: Those that are believed to
have a good enough quality to go in but haven't been sent yet, those
that aren't there yet (if for example user space interfaces may
change) but have someone working on bringing them closer to the
quality needed to get them into the stable parts of Linux, those that
aren't there and aren't being worked on and those drivers that
duplicate upstream drivers. I don't know what driver is in what class
since thing may have changes since [1]. I know that some drivers have
been merged and others have had alternatives merged since then but I'm
unsure about the rest.

If my understanding of the process for Linux development is correct
the situation is this: Drivers that are believed to be in the first
class could go right into the stable parts of the Linux kernel. On the
other hand they could have issues and it could take time to get the
maintainers of the correct sub systems to review them. They could also
go into staging with an "ask for feedback" in the todo. Drivers in the
second category could only go into staging. (With issues that needs to
be fixed in the todo) Drivers in the third category can't even go into
staging unless they're already in widespread use or someone is willing
to work on them. Drivers in staging can be thrown out if they don't
make progress but unlike staying in a separate tree they will get more
upstream attention. The attention means more people working to clean
them up, help to change them when API's changes, etc.

Since my C currently isn't the best I don't think I can help with
drivers that don't have others working on them as well. But I realize
that in addition to technical issues there are also other issues that
may delay submitting code upstreams like getting the author
information right. One thing I could do is to try to get patches
containing the drivers and the authorship information that are in the
second class or in the first class (but not expected to be submitted
before after 2.6.36) into staging. Before sending them I would check
Andy-tracking, the 2.6.3x series on git.openmoko.org, the source code
and other sources for authorship information (if someone could point
them out to me) to get the authorship correct. Then I would ask on
this list if anyone feels left out just to be sure before sending
them. If they were accepted into staging I could post patches for the
trees on git.openmoko.org to move the code into the staging directory
there as well to make patches easier to port between them and the
upstream tree. I would also try to forward patches committed there to
staging if the author doesn't. If other issues than getting authorship
right and the act of sending patches are in the way of getting them
closer to upstream I could try to solve them if they are pointed out
to me. For example I think that my C is good enough to convert drivers
that include firmware to use firmware loader to avoid legal issues if
a driver has that kind of problems.

If you think this sounds like a good idea please give me a hint about
what driver(s) I could start with. If not please tell me why. If you
have other ideas on how I can help make the drivers move upstream (or
closer to upstream like staging) faster please tell me so I can
consider it.

Sincerely
Sveinung Kvilhaugsvik

[1] http://lists.openmoko.org/pipermail/openmoko-kernel/2009-July/010379.html

Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming (offer to help)

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Sveinung Kvilhaugsvik wrote:

> Hello
>
> What is holding the drivers for the Freerunner back from being
> merged upstream? Can I do something to help? Following is a
> suggestion for what I could do. (Please be aware that English is
> not my native language. So if something is unclear, impossible to
> understand, easy to misunderstand or written in an insulting tone
> please ask me to clarify)
>
> First some background on my thinking. I think the drivers that
> still are missing can be divided in four classes: Those that are
> believed to have a good enough quality to go in but haven't been
> sent yet, those that aren't there yet (if for example user space
> interfaces may change) but have someone working on bringing them
> closer to the quality needed to get them into the stable parts of
> Linux, those that aren't there and aren't being worked on and those
> drivers that duplicate upstream drivers. I don't know what driver
> is in what class since thing may have changes since [1]. I know
> that some drivers have been merged and others have had alternatives
> merged since then but I'm unsure about the rest.

Those that are believed to have a good enough quality to go in but
haven't been
sent yet:
No driver in this category

those that aren't there yet (if for example user space interfaces may
change)
but have someone working on bringing them closer:
That would be the powermanagement drivers and glamo+jbt

those drivers that duplicate upstream drivers:
Thats bq27000, but I have WIP for merging it with the bq27x00 driver.

And a fifth category: Those which are never going to be upstream: AR6000

>
> If my understanding of the process for Linux development is correct
>  the situation is this: Drivers that are believed to be in the
> first class could go right into the stable parts of the Linux
> kernel. On the other hand they could have issues and it could take
> time to get the maintainers of the correct sub systems to review
> them. They could also go into staging with an "ask for feedback" in
> the todo. Drivers in the second category could only go into
> staging. (With issues that needs to be fixed in the todo) Drivers
> in the third category can't even go into staging unless they're
> already in widespread use or someone is willing to work on them.
> Drivers in staging can be thrown out if they don't make progress
> but unlike staying in a separate tree they will get more upstream
> attention. The attention means more people working to clean them
> up, help to change them when API's changes, etc.
>
Well, the only driver that would qualify for staging is the glamo
driver. But I'm not sure if it really makes sense to put it into
staging. The only known HW platform using the glamo is the Freerunner.
And the current distributions for the Freerunner build the kernel from
the openmoko git kernel tree anyway.
On the other hand having to send each patch through staging might slow
things down.

> Since my C currently isn't the best I don't think I can help with
> drivers that don't have others working on them as well. But I
> realize that in addition to technical issues there are also other
> issues that may delay submitting code upstreams like getting the
> author information right. One thing I could do is to try to get
> patches containing the drivers and the authorship information that
> are in the second class or in the first class (but not expected to
> be submitted before after 2.6.36) into staging. Before sending them
> I would check Andy-tracking, the 2.6.3x series on git.openmoko.org,
> the source code and other sources for authorship information (if
> someone could point them out to me) to get the authorship correct.
> Then I would ask on this list if anyone feels left out just to be
> sure before sending them. If they were accepted into staging I
> could post patches for the trees on git.openmoko.org to move the
> code into the staging directory there as well to make patches
> easier to port between them and the upstream tree. I would also try
> to forward patches committed there to staging if the author
> doesn't. If other issues than getting authorship right and the act
> of sending patches are in the way of getting them closer to
> upstream I could try to solve them if they are pointed out to me.
> For example I think that my C is good enough to convert drivers
> that include firmware to use firmware loader to avoid legal issues
> if a driver has that kind of problems.
>
> If you think this sounds like a good idea please give me a hint
> about what driver(s) I could start with. If not please tell me why.
> If you have other ideas on how I can help make the drivers move
> upstream (or closer to upstream like staging) faster please tell me
> so I can consider it.
>
> Sincerely Sveinung Kvilhaugsvik
>
> [1]
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-July/010379.html
>

Thanks for your help.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwREJ0ACgkQBX4mSR26RiOHXACfYadho1r3pnu7H2FBfp4DFi5O
mLgAnR83lm2vYPzaHC7jH6vfRXJjywfu
=LWzM
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming (offer to help)

Thibaut Girka
Hi,

Le jeudi 10 juin 2010 à 18:19 +0200, Lars-Peter Clausen a écrit :
> Well, the only driver that would qualify for staging is the glamo
> driver. But I'm not sure if it really makes sense to put it into
> staging. The only known HW platform using the glamo is the Freerunner.

That's a valid point.

> And the current distributions for the Freerunner build the kernel from
> the openmoko git kernel tree anyway.

Some people (and I'm one of them) are running Debian on their FreeRunner
and would like to have everything needed in the official Debian archive.

However, Debian builds every kernel from the same source, so, the
openmoko git kernel tree won't ever be used for any official Debian
kernel.

Having glamo and jbt upstream would benefit to Debian, and maybe other
distributions.
The drivers would probably benefit from more exposure, too.

Best regards,
Thibaut Girka.

signature.asc (205 bytes) Download Attachment