new kernel ... / meaning of stable-tracking

Mike (mwester) mwester at
Mon Sep 29 19:30:44 CEST 2008

Sean McNeil wrote:
> Mike (mwester) wrote:
>> Werner Almesberger wrote:
>>> I'm actually very surprised by your hostile reaction to this change.
>> You are unilaterally making the decision to replace existing
>> functionality with something that provides considerably lesser
>> functionality, yet you have never proven the case that the lost
>> functionality is, in fact, extraneous.
>> But, hey -- it's clear your mind is made up, so we'll all just start
>> getting used to pulling the back off the device and removing the
>> battery.  This discussion, like the others involving removal of debug
>> and test code, seems to result in the same thing: if it's something the
>> core developers want, it goes in, but if it's something the user
>> community wants, they can fork the kernel and write it their way.  My
>> apologies for thinking this might be open for discussion.
> I find all this very counter-productive. For one thing, you are asking
> unilaterally that the code remain and don't want to discuss the options.
> It would be a lot more helpful if you could make a strong case to keep
> it in place. Let me start with what I observe:
> 1) The only time my system freezes is because of resume failing. This
> requires me to remove the battery anyway. The power-off by holding down
> the key 8 seconds will not work.
> 2) My software stack already has keep-alive functionality and I have no
> use for the kernel functionality.
> 3) As stated, the fewer application specific things in the kernel the
> better. I would not categorize this as debug code, but a convenient hack
> so a kernel watchdog process didn't have to be written.
> So, if you could please give us clear reasoning why you feel that the
> code should be kept in place, I think we would all like to understand
> your position better. I do not think the argument "because it is already
> there" or "because I have to pull the battery out to reboot" is good
> enough. The latter can be fixed another way as Werner has demonstrated.

So it gets down to a "burden of proof" thing, doesn't it?  You have your
own distro (which AFAIK is not public and not what is under discussion
at this time).  I'm delighted that your system never has any user-space
issues that cause any trouble -- that demonstrates that at some point
there's hope that we won't need this for the public distros!

As for the final point, you throw the burden of proof back on users to
come up with use cases.  We've responded in the previous emails.  And
you're a kernel developer -- you know perfectly well what can happen to
kernel space, so you don't need me to tell you all about running systems
out of memory, filling up flash space, runaway threads, etc, etc.

Maybe the correct thing to do in this case is for you to maintain a
patch to remove this functionality that you don't need?  It seems clear
that in terms of maturity and stability, your project is quite unique
from any of the public distros.


More information about the openmoko-kernel mailing list