Hi,
Am 14.06.2018 um 13:01 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
I'm not sure whether we use the Letux Kernel as is or whether we
apply some patches (or our own config file).
Yes, there should be a different config for the PyraOS. Letux OS has a lot of stuff not needed and compiling more things into the kernel reduces boot time.
Okay. So if we can keep the config file for the Pyra included in the Letux Kernel, then I'm perfectly fine if we use that one.
Even if we simply use a modified configuration, this needs to be available. If someone wants to compile the exact same kernel as is running on the retail unit, he also needs a changed config file. So, the main question is: How should we handle that? Should we simply use the LETUX kernel as is?
The question is if you want to maintain it or if we simply integrate it into the letux git tree. This would make it easier for people to either make letux_defconfig or let's say make pyra_defconfig. This could help especially if there are problems.
If the only change we have is a different config and this could be integrated into the Letux kernel tree, then that would be best in my opinion.
@aTc: I guess our Debian image creator can grab the source from the Letux Kernel and use the Pyra config for compilation, right?
Could you please provide the config file so Nikolaus can include it? And let us know if there are any other patches that might be needed?
That would easiest, however, we need to make sure we provide kernels that don't break anything serious (for example, one of the last releases broke audio - this should NEVER EVER happen if a normal user updates his system).
That is a matter of of doing enough and repeated regression testing. What I do with the Letux kernel is to have "latest" version and a "work-in-progress" version. The "latest" one has been tested as good as possible (more testing is always possible and may reveal additional bugs). Only if the "mainline" thing has fixed known bugs, it becomes the "latest" kernel which is installed by normal users.
I'm not sure which one aTc tried. If it was stable that rendered audio unusable, then it's fine. If it was testing / stable, then such critical things shouldn't happen :)
@Nikolaus: Do we have a way to ensure this doesn't happen?
I don't have it, but we as a group can do more testing than in the past...
Well, yes, but who decides when a kernel is testing or stable? If this decision is made before it's thoroughly tested, the system itself is broken ;)
Ideally, we would provide an unstable- or stable kernel in our OS, so every user can help with testing if he wants to.
That is how Letux OS is organised. The missing piece are enough testers, not a process or a repository or structure.
Okay, then I guess we can work together here and implement the Pyra config into the Letux kernel first.
Another option would be to setup a git on our gitlab which would be basically a clone of the Letux kernel git with changes / additions that should not find their ways into the default Letux kernel.
Hm. Are there any? I see (at least at the moment) no reason or example what should not go into Letux.
I have no idea what the status is right now. But I can imagine that implementing some hacks to improve power saving on the Pyra but is not useful for everyone else could be something potential.
Well, power saving is useful for everyone :)
But yes there might be a conflict: hack someting into the kernel that only works on the Pyra and breaks other things or hack it in a way that it is gracefully ignored on other devices (e.g. OpenPandora).
We had such a thing with the TILER patches which did break the omapdss on OMAP3. But we were able to fix it so that it doesn't break OMAP3 any more. That is some percent of extra effort.
But if we ever want to get things upstrem, we have to do that anyways.
But we can always take care of that if that ever happens.
So of course, if there are no drawbacks using the Letux kernel and we can implement our own set of config and maybe patches there, there's no reason for our own repository.
That would be my preference :)
Mine too. So I wait for some defconfig to include (and patches for improvement).
BR, Nikolaus