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
