[Letux-kernel] Organization Kernel for retail OS

[Michael Mrozek]

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

-- 
-- 
Greetings,

Michael Mrozek

-----------------------
OpenPandora GmbH
CEO: Michael Mrozek

Schäffbräustr. 11
85049 Ingolstadt
Germany
Tel.: +49 841 990 5548
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek at openpandora.org