Hi,
we had a little chat on IRC and here is what we thought would be the best way to move forward.
Our idea is to:
* Use the Letux kernel as base for the Pyra one. We only want to add our own things that do not work with the Letux kernel philosophy.
* Therefore, patches that are compatible with all the systems supported by the Letux kernel should be applied directly to the Letux kernel
* Other patches that are NOT compatible with all systems (e.g. latest 3D driver, that does not support older systems like the OMAP3, etc.) will be added on our own kernel git.
The reasons to not simply use the Letux kernel are:
* There are tons of different branches and releases which makes it a bit complicated for Pyra devs to find out what the one used currently by the Pyra is
* Some drivers (like 3D, as mentioned, or LPAE) are not compatible with systems the Letux kernel supports.
First question: Is everyone okay with that? Or does someone have a better suggestion?
What we urgently need is someone who wants to set that up. I can provide GIT, webspace, whatever, but I can't code and certainly I'm not knowleadgable enough how to set the GIT up properly, so that it basically updates itself from other GIT sources where we can put our own things on top, etc.
Second question: Any volunteers?
So, anyone here who wants to do that? Most work is probably setting that up properly, once it's done and the kernel builds from our git and we can update it and add our own patches, work should be minimal (correct me if I'm wrong). And we'd also need to know which of the Letux branches is the best one to use for that.
Third question: How to provide patches to the Letux Kernel
There have been some differences in the past because hns added some half-finished TILER code from zmatts git which was not meant to be added yet. That's something I want to prevent in the future.
Of course, there's some conflict: On the one side, the TILER code wasn't meant for productive kernels (as it was a quick hack), but on the other side, it was needed to have a rotated picture on the Pyra.
So yes - I have no idea what the correct solution here would've been... maybe to NOT add it to a public repo but only for own compilations?
Well, hopefully, the code for that can be cleaned up soon so that it can be officially included.
However, it is unclear to me (and possibly to others) how the Letux kernel development in set up, what the different branches are, how to provide patches to the Letux kernel, etc.
Nikolaus, do you have a brief description somewhere on your website, that explains your ideas and the setup of the Letux kernel?
I hope I got everything correctly. Let me know if I didn't.
Am 04.07.2017 um 02:09 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
we had a little chat on IRC and here is what we thought would be the best way to move forward.
Our idea is to:
- Use the Letux kernel as base for the Pyra one. We only want to add
our own things that do not work with the Letux kernel philosophy.
What are these?
- Therefore, patches that are compatible with all the systems supported
by the Letux kernel should be applied directly to the Letux kernel
Ok.
- Other patches that are NOT compatible with all systems (e.g. latest
3D driver, that does not support older systems like the OMAP3, etc.) will be added on our own kernel git.
Hm. I would like to have the latest 3D driver as well in Letux. In a way that there are loadable modules for OMAP3 and OMAP5.
The reasons to not simply use the Letux kernel are:
- There are tons of different branches and releases which makes it a
bit complicated for Pyra devs to find out what the one used currently by the Pyra is
Hm. That comes from the way the Linux development process forces us to do. I would be happy if we could do it simpler, but it did not work well by just piling up patches for everything in a single master branch.
Basically there are:
* letux-base - which is the current linus/master plus some patches not yet processed * feature branches (one per feature so that cleaning and upstreaming can be done in small pieces) * abandoned feature branches (that were replaced by newer versions or are no longer needed) * merged letux trees
That is all. If you look at them by
http://git.goldelico.com/?p=gta04-kernel.git;a=heads
there is the latest merge result at top. Then follow all active feature branches. Up to letux-base. Everything below is old stuff.
- Some drivers (like 3D, as mentioned, or LPAE) are not compatible with
systems the Letux kernel supports.
LPAE is not a driver, it is a different defconfig. I create it from the letux_defconfig by a shell script with some sed commands before starting make. So it is more a compile-option.
IMHO the Pyra release kernel should have a separate defconfig which disables OMAP3/4 support, enabled LPAE and removes unneeded drivers.
It should also compile into the kernel what is always needed (currently most modules are loaded, slowing down the boot process but speeding up debugging).
And there should be an initramfs to show some graphical boot screen. Maybe this needs a second pyra_boot_defconfig.
First question: Is everyone okay with that? Or does someone have a better suggestion?
What we urgently need is someone who wants to set that up. I can provide GIT,
The git already exists and is just used as a mirror of the Letux git:
ssh://git.openpandora.org/srv/git/pyra-kernel.git
webspace, whatever, but I can't code and certainly I'm not knowleadgable enough how to set the GIT up properly, so that it basically updates itself from other GIT sources where we can put our own things on top, etc.
Second question: Any volunteers?
So, anyone here who wants to do that? Most work is probably setting that up properly, once it's done and the kernel builds from our git and we can update it and add our own patches, work should be minimal (correct me if I'm wrong). And we'd also need to know which of the Letux branches is the best one to use for that.
Third question: How to provide patches to the Letux Kernel
Either by sending patches by e-mail here on this list (like it is commonly done on LKML).
Or by me giving write access and pushing to new feature branches.
Or if someone has his own git repo, I can pull patches if I am told where to look at.
There have been some differences in the past because hns added some half-finished TILER code from zmatts git which was not meant to be added yet. That's something I want to prevent in the future.
This can't be prevented technically. It was a misunderstanding of each other's motivations and cautioness and quality expectations.
Of course, there's some conflict: On the one side, the TILER code wasn't meant for productive kernels (as it was a quick hack), but on the other side, it was needed to have a rotated picture on the Pyra.
So yes - I have no idea what the correct solution here would've been... maybe to NOT add it to a public repo but only for own compilations?
My view is: add everything in the public. Even if it has very low quality and you know that it is complete crap. This allows others to build upon and make proposals to increase quality.
Well, hopefully, the code for that can be cleaned up soon so that it can be officially included.
A problem with "officially" needs to be paraphrased into: who is gatekeeper for what. This means "Quality Gates". I.e. a gatekeeper takes what is new and makes a decision to accept or reject for rework.
For Letux, I am the gate keeper. For Upstream there is a hierarchy of gate-keepers. And Linus is the last stage.
For Pyra-kernel it could be someone else. Taking the letux git and other stuff and decide what is going in and what is deleted before a release is tagged "official".
Note: this is orthogonal to "public" vs. "private". Private branches can be "official" and "public" ones can be "inofficial".
Or again in other words: which quality level makes something "official" must be decided. And there are multiple levels of "official".
At the moment I am happy if we have anything for all features (for some we even haven't). I combine patches of low quality with others we have working flawless for years to have something to show and use. pitSebs pictures show what already works (even if e.g. the Tiler or bq24297 drivers are viewed completely as crap by the authors and light years away from even thinking about submission to LKML).
However, it is unclear to me (and possibly to others) how the Letux kernel development in set up, what the different branches are, how to provide patches to the Letux kernel, etc.
I mentioned some aspects above.
But basically it follows the linux-next approach.
linux-next regularily checks out linus/master and merges a big set of subsystem branches on top. So that a running system results, but is not "officially" accepted by Linus. It is already reviewed but sometimes things are thrown out because bugs have slipped in. And not all bugs are found in this phase (or we wouldn't have 3.4.113 meaning 113 reworks after ca. 8 release candidates after linux-next).
Linux-next is built by pulling these (external) branches.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Nex...
Letux is built by merging these (local) branches:
http://download.goldelico.com/letux-kernel/letux-4.12/src/mergefile
So to summarize: linux-next is a collection of (already reviewed) subsystem patches on top of linus/master and describes what the next Linux -rc1 should (almost) look like.
Letux is a collection of feature branches of very different maturity on top of linus/master which describes what we want and need to have to make the devices at least a little useable in daily operation.
And since it is the best re-mix we currently have (we are not replacing existing features but making thing work for the first time), it is the best we have for daily use.
Nikolaus, do you have a brief description somewhere on your website, that explains your ideas and the setup of the Letux kernel?
I have found a 2 years old picture and updated a little:
http://projects.goldelico.com/p/gta04-kernel/downloads/66/
Questions welcome.
I hope I got everything correctly. Let me know if I didn't.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 04.07.2017 um 11:49 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 04.07.2017 um 02:09 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
we had a little chat on IRC and here is what we thought would be the best way to move forward.
Our idea is to:
- Use the Letux kernel as base for the Pyra one. We only want to add
our own things that do not work with the Letux kernel philosophy.
What are these?
- Therefore, patches that are compatible with all the systems supported
by the Letux kernel should be applied directly to the Letux kernel
Ok.
- Other patches that are NOT compatible with all systems (e.g. latest
3D driver, that does not support older systems like the OMAP3, etc.) will be added on our own kernel git.
Hm. I would like to have the latest 3D driver as well in Letux. In a way that there are loadable modules for OMAP3 and OMAP5.
The reasons to not simply use the Letux kernel are:
- There are tons of different branches and releases which makes it a
bit complicated for Pyra devs to find out what the one used currently by the Pyra is
There is also some landing page:
http://projects.goldelico.com/p/gta04-kernel/
You can simply click on the "stable / sources" link in the table and are guided to the right head/commit. Or if you want the "release" candidate, click there.
The binary downloads area also contains such links, e.g.:
http://download.goldelico.com/letux-kernel/letux-4.12-lpae/src/
Hm. That comes from the way the Linux development process forces us to do. I would be happy if we could do it simpler, but it did not work well by just piling up patches for everything in a single master branch.
Basically there are:
- letux-base - which is the current linus/master plus some patches not yet processed
- feature branches (one per feature so that cleaning and upstreaming can be done in small pieces)
- abandoned feature branches (that were replaced by newer versions or are no longer needed)
- merged letux trees
That is all. If you look at them by
http://git.goldelico.com/?p=gta04-kernel.git;a=heads
there is the latest merge result at top. Then follow all active feature branches. Up to letux-base. Everything below is old stuff.
- Some drivers (like 3D, as mentioned, or LPAE) are not compatible with
systems the Letux kernel supports.
LPAE is not a driver, it is a different defconfig. I create it from the letux_defconfig by a shell script with some sed commands before starting make. So it is more a compile-option.
IMHO the Pyra release kernel should have a separate defconfig which disables OMAP3/4 support, enabled LPAE and removes unneeded drivers.
It should also compile into the kernel what is always needed (currently most modules are loaded, slowing down the boot process but speeding up debugging).
And there should be an initramfs to show some graphical boot screen. Maybe this needs a second pyra_boot_defconfig.
First question: Is everyone okay with that? Or does someone have a better suggestion?
What we urgently need is someone who wants to set that up. I can provide GIT,
The git already exists and is just used as a mirror of the Letux git:
ssh://git.openpandora.org/srv/git/pyra-kernel.git
webspace, whatever, but I can't code and certainly I'm not knowleadgable enough how to set the GIT up properly, so that it basically updates itself from other GIT sources where we can put our own things on top, etc.
Second question: Any volunteers?
So, anyone here who wants to do that? Most work is probably setting that up properly, once it's done and the kernel builds from our git and we can update it and add our own patches, work should be minimal (correct me if I'm wrong). And we'd also need to know which of the Letux branches is the best one to use for that.
Third question: How to provide patches to the Letux Kernel
Either by sending patches by e-mail here on this list (like it is commonly done on LKML).
Or by me giving write access and pushing to new feature branches.
Or if someone has his own git repo, I can pull patches if I am told where to look at.
There have been some differences in the past because hns added some half-finished TILER code from zmatts git which was not meant to be added yet. That's something I want to prevent in the future.
This can't be prevented technically. It was a misunderstanding of each other's motivations and cautioness and quality expectations.
Of course, there's some conflict: On the one side, the TILER code wasn't meant for productive kernels (as it was a quick hack), but on the other side, it was needed to have a rotated picture on the Pyra.
So yes - I have no idea what the correct solution here would've been... maybe to NOT add it to a public repo but only for own compilations?
My view is: add everything in the public. Even if it has very low quality and you know that it is complete crap. This allows others to build upon and make proposals to increase quality.
Well, hopefully, the code for that can be cleaned up soon so that it can be officially included.
A problem with "officially" needs to be paraphrased into: who is gatekeeper for what. This means "Quality Gates". I.e. a gatekeeper takes what is new and makes a decision to accept or reject for rework.
For Letux, I am the gate keeper. For Upstream there is a hierarchy of gate-keepers. And Linus is the last stage.
For Pyra-kernel it could be someone else. Taking the letux git and other stuff and decide what is going in and what is deleted before a release is tagged "official".
Note: this is orthogonal to "public" vs. "private". Private branches can be "official" and "public" ones can be "inofficial".
Or again in other words: which quality level makes something "official" must be decided. And there are multiple levels of "official".
At the moment I am happy if we have anything for all features (for some we even haven't). I combine patches of low quality with others we have working flawless for years to have something to show and use. pitSebs pictures show what already works (even if e.g. the Tiler or bq24297 drivers are viewed completely as crap by the authors and light years away from even thinking about submission to LKML).
However, it is unclear to me (and possibly to others) how the Letux kernel development in set up, what the different branches are, how to provide patches to the Letux kernel, etc.
I mentioned some aspects above.
But basically it follows the linux-next approach.
linux-next regularily checks out linus/master and merges a big set of subsystem branches on top. So that a running system results, but is not "officially" accepted by Linus. It is already reviewed but sometimes things are thrown out because bugs have slipped in. And not all bugs are found in this phase (or we wouldn't have 3.4.113 meaning 113 reworks after ca. 8 release candidates after linux-next).
Linux-next is built by pulling these (external) branches.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Nex...
Letux is built by merging these (local) branches:
http://download.goldelico.com/letux-kernel/letux-4.12/src/mergefile
So to summarize: linux-next is a collection of (already reviewed) subsystem patches on top of linus/master and describes what the next Linux -rc1 should (almost) look like.
Letux is a collection of feature branches of very different maturity on top of linus/master which describes what we want and need to have to make the devices at least a little useable in daily operation.
And since it is the best re-mix we currently have (we are not replacing existing features but making thing work for the first time), it is the best we have for daily use.
Nikolaus, do you have a brief description somewhere on your website, that explains your ideas and the setup of the Letux kernel?
I have found a 2 years old picture and updated a little:
http://projects.goldelico.com/p/gta04-kernel/downloads/66/
Questions welcome.
I hope I got everything correctly. Let me know if I didn't.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-
H. Nikolaus Schaller -
Michael Mrozek