On Tue, 22 Oct 2002 13:15:52 +0900
Jorgen Lundman <lundman@lundman.net> wrote:

> I do feel a bit for the original patcher of this thread, who thought it 
> be nice to offer his diffs, told to do something more "proper" then shot 
> down because it's bloat. Not complaining or putting blame on anyone, it 

> just puts people off contributing, I know it did for me.

I'll "summarize" how the discussion has progressed ;-). Lets call the initial
author A, because this is applicable to other threads (I just remember console
scrolling, which had a similar discussion and... where is the code now? the
author just got bored of the discussion). :-(

1. A thinks it could be good to have a feature in kernel and writes it.
2. A submits this feature to tech-kern for oppinions/review.
3. Somebody comes up saying it's a good idea, but need to be more customizable
   (at least, all its details).
4. A gets to work again, modifies the patch to be all customizable and reposts
   it.
5. Somebody else comes and says it should be sysctl'able. Seems a good idea
   to A (and is suggested by several people).
6. A gets to work again, modifies the patch to support sysctl and reposts it.
7. Somebody else comes and says that sysctl variables should be organized in
   cathegories rather than using dashes _. A thinks that's true, but will add
   more overhead to the code.
8. A gets to work again, modifies the patch to use more levels in sysctl and
   reposts again, thinking it's ok now.
9. Somebody else comes and says that the idea should be implemented in a more
   generic way. It's nice, but this means more and more overhead and is out of
   initial objectives.
10. Somebody else comes and says that the new code is too big and the original
    patch was far better (smaller). Although, the kernel size only grows in
    half a kilobyte (compiled).
11. Everybody disagrees now.
12. A gets bored and leaves his work.

I feel that the Kernel Programming FAQ should include several "official
recommendations" on how to implement new features (wether they need sysctl or
not, how to customize them)...

Conclusions (related to the initial idea):
1. Code must be optional in kernel.
2. It must use sysctl (as seems a general concensus).
3. It should be extensible (this comes the most problematic work).
4. Several people seems to like the idea.
5. There is a similar idea already implemented in another architecture (BLINK)
   so this one is not silly.
6. kern.evt.onhalt.* (where * is beep.*) has been suggested, so that new kind
   of "events" can be easily added, instead of kern.beep.onhalt.*. The .evt
   level will simplify sysctl's code (ugg, this is evil).
7. If such a thing is implemented, it "should" be designed well from the
   beginning. Do you see now? Is this the same as the initial proposal?
   Completely different.
8. Other people say that all of this is much code and should not be done this
   way (a simple kernel option is enough, i.e., original patch).

So, I'm afraid. I guess: I'll reorder sysctl calls to add the new level, and
more inconvenients will come... (like: this is not properly designed, or it
is getting too big, or...)

Regards

PS: Just to say that the last patch was a bit longer than the other ones
because, between other reasons, I added the "onreboot" event, just to show
it was easy... I think now that beep on reboot is useless.

-- 
Julio Merino (http://jmmv.dyndns.org/) <jmmv@menta.net>