new kernel ... / meaning of stable-tracking

[Sean McNeil]

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.

Cheers,
Sean