new kernel ... / meaning of stable-tracking
sean at mcneil.com
Mon Sep 29 20:09:58 CEST 2008
Mike (mwester) wrote:
> 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!
This software stack will be released soon. You will have the chance to
play with it before the end of the year.
> 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.
What I would like to see happen is more discussion as to why you feel
this way. You obviously have very strong opinions and feel you aren't
being heard. Please concentrate on what you feel a watchdog process
There are many ways we can approach this:
We could use the drivers/watchdog/s3c2410_wdt.c to make sure the
application layer never freezes.
We could create a new watchdog.
We can make the code conditionally compiled.
We can put it in the debug-only kernel.
The neodog program can be enhanced to satisfy all your needs.
Please work with us to meet your concerns.
> 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