[Letux-kernel] Organization Kernel for retail OS

H. Nikolaus Schaller hns at goldelico.com
Thu Jun 14 12:24:55 CEST 2018


let me answer to both mails in one...

> Am 14.06.2018 um 09:55 schrieb Mr C Camacho <chriscamacho at virginmedia.com>:
> I'd really appreciate the inclusion of .config support in the kernel and also /proc/config.gz support
> I always include these in any VM experiments, so even if all I have is the binary kernel left over (at a later date), I can still recreate the kernel or use the old config to recreate a config on a newer source...

It is enabled by letux_defconfig:

root at letux:~# ls -l /proc/config.gz 
-r--r--r-- 1 root root 35509 Jun 14 10:10 /proc/config.gz
root at letux:~# 

> On 14/06/18 03:26, Michael Mrozek wrote:
>> As we're getting closer to release, it's important in my opinion that
>> we clean up things a bit and organize things.
>> As you probably saw in my last email, I don't even know where to get
>> everything - and that should be well documented on a website (ideally
>> on https://dev.pyra-handheld.com/ ).
>> I can summarize everything there, but we first need to get a good
>> structure and make some decisions how to proceed, as (in my opinion),
>> it's a bit of a mess right now.
>> Let's start with the kernel:
>> 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

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

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

It is sort of beta version vs. production version. Developers sometimes
have additional alpha-code on top of it.

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

>> Is the stable-release on your kernel GIT tested properly?

Definitively NO, because there is no definition of "properly" and
who is doing that.

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

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

>> This would be a bit cleaner in my opinion, as we would have everything
>> together in our own git-repos - even if we use vanilla Letux without
>> any changes.

Well, depends if you want to form two groups of developers "we" vs. "they"
with potential issues.


More information about the Letux-kernel mailing list