[ On Sunday, October 20, 2002 at 11:43:09 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: Beep on halt (definitive?)
>
> On Sun, Oct 20, 2002 at 08:03:29PM +0200, der Mouse wrote:
> 
>  > The point of machdep.beep.onhalt (or whatever it's called) is that it
>  > tells you when it *is* safe to power off.  Not all machines have soft
>  > power, y'know. :-)
> 
> This is just needless kernel bloat.

For you maybe, but even with a serial console on all my headless
machines, I can certainly appreciate the idea.  If my head is stuck in
the back of the cabinet when the machine utters its final beep then I
don't have to go back around to check and make sure it's really and
truly down and quiescent before I pull the plug.  It might be a small
gain (and I should get the excercise), but it's a very extremely small
price to pay for the feature.

For me _all_ power-management goo in the kernel on anything but a laptop
is kernel bloat.

I do admit to showing off my 3B2's ability to power itself off long
before any other computer of its size had any even remotely similar
capability!  :-)

However these days I'd much rather have a front-end/baseboard/whatever
management processor controlling the power supply, such as the LOM on
the new SunFire Vxxx machines.  I don't want that level of management
inside my kernel (only access to the data collection side) because my
kernel cannot reliably toggle the hardware reset line like a FEP/BMC/LOM
controller can, or any other number of similar tricks that really need
to be done with an "out-of-band" management controller.

Eg. it cannot power up the machine again after it has powered down like
the LOM controller can!  ;-)

Even an intelligent external power controller could ultimately be
better than what my 3B2 could do if it had some way to notice when the
kernel had actually finished and halted.  Now of course I'm not talking
about such a thing having a microphone that could listen for beeps, but
if this "beep on halt" were set up like this then maybe something along
these lines could be done easily with existing hardware, while still at
the same time allowing the current behaviour where possible:

	kern.onhalt.beep		# read-only capability indicator
	kern.onhalt.beep.DEVICE	
	kern.onhalt.beep.pitch
	kern.onhalt.beep.duration
	kern.onhalt.beep.repetitions
	kern.onhalt.devout.dtr		# read-only capability indicator
	kern.onhalt.devout.dtr.TTYNN
	kern.onhalt.devout.dtr.TTYXX
	kern.onhalt.devout.dcd
	kern.onhalt.devout.dcd.TTYNN
	kern.onhalt.devout.dcd.TTYXX
	kern.onhalt.powerdown		# reads -1 if not supported?

And no, this shouldn't go in the machdep group.  This is a kenel
capability, not something specific to a given type of machine (even
though not all the options of this capability might be available on any
given machine).

In the other world where the "MIB" concept comes from the idea of a
vendor or platform specific set of attributes and capabilities is
strongly discouraged since the idea is to describe and manage and
measure generic attributes and capabilities, not to require
administrators and developers to bend and twist and gyrate for every
variant they might encounter.  The same should be done for sysctl on a
portable OS.  If some control or measurement or attribute is not
supported on a given platform then there should be a way to represent
the fact it's missing while still showing it in the hierarchy where it
most naturally fits.

I.e. machdep is a very bad and ugly hack and really should be abolished.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>