Further to my recent exploration of the front panel LEDs on an ISP1100,
and some discussinos on port-i386, here's a Proposal for a kernel thingy
that will be of use to the administrators of large server clusters.

Many machines have user-controllable front panel LEDs - cobalt Qubes,
assorted Sun kit, and things like the i386 Intel ISP1100 boxen I've been
playing with.

I've also seen machines with pushbuttons and dot matrix displays.

We also need to think about supporting SMBus stuff like temperature
monitors in future as well.

Therefore, I propose /dev/chassis...

/dev/chassis will mainly be used through ioctls. Any data written to
/dev/chassis will be displayed on the currently selected dot matrix
display panel, or discarded if there are none. Reading from /dev/chassis
will result in event codes from event sensors such as pushbuttons being
received; the reading process will of course block until an event occurs.

I will propose a complete and complex specification, but I will only
expect small parts of it to be implemented at a time. /dev/chassis will be
a multiplexing access point to various devices, from SMBus interfaces to
front panels and other toys.

/dev/chassis will support various ioctls:

Query hardware: return a list of chassis devices available. A chassis
device can be an indicator, with a name and a list of named states
(simple LEDs get "on" and "off", for example; while the status LED array
on the ISP1100 will have four states, "on", "sleep", "fault1", and
"fault2"). Or it can be a display panel, with a name and a displayable
character grid size. Or a switch with a name and a list of named
settings. Or a pushbutton with a name. Or a sensor with a name, a unit
(volts/amps/degress C), a level, and a nominal level (eg, the nominal
level of the 12V power rail would be 12V).

Get/Set Device Status: get or set the state of something. Setting the
state of a pushbutton, switch, or sensor is meaningless. The state of a
display panel is "selected" or "unselected"; only one can be selected at
once. The selected display panel is written to by data writes to
/dev/chassis.

CreateState: given a name and a series of device name: status pairs,
"remembers" that set of device statuses as a state. The special state
"kernel_panic", if it exists, is automatically selected (see
SetState) when the kernel panics. The special state "sched_idle" is
selected when the idle process is scheduled. The special state
"sched_user", "sched_kern", "sched_intr", etc. are selected when the
scheduler is running different types of code, obviously.

FlushStates: Clears the state list

SetState: given a state name, sets all the devices listed in the state to
the associated statuses.

The utility /sbin/chassisctl provides the following options:

-f <file> - load a chassis.conf file that specifies states
-s <state> - selects state S

-l - list all the devices known to the chassis driver

--set <device> <status> - set the status of a device
--get <device> - get the status of a device (to stdout)

/etc/rc should perform a "/sbin/chassisctl -f /etc/chassis.conf
; /sbin/chassisctl -s sys_boot", then when bootup is complete and the
system is considered "up", "/sbin/chassisctl -s sys_up". init should
execute "/sbin/chassisctl -s sys_halted" and "/sbin/chassisctl -s
sys_single_usr" at appropriate points, too.

As a later extension, a "chassisd" could be written that open /dev/chassis
for reading and reads "events" of the form:

<device name>:<old status>:<new status>\n

I'd be inclined to encode that in a packed structure rather than ASCII, if
only to avoid dealing with variable sized buffers in the kernel too much.

"chassisd" should be programmeable to run scripts when events arrive. The
rest is up to the user; buttons may be wired up to "shutdown -r now",
"apachectl restart", etc. and switches wired to start or stop
services. Monitoring scripts would warn of sensors going out of acceptable
ranges. And all without needing polling.

I would hope to write chassisctl, chassisd, and the in-kernel state
switching stuff for /dev/chassis. At the moment, we have very few drivers
that could register with the chassis multiplexor; I can only think of LED
devices myself, but maybe something vould be done with USB HIDs...

The advantage, for now, is that we can set up machines like ISP1100s to
show useful front panel information, and that we have an architecture to
grow into supporting SMBus (FreeBSD has limited support already IIRC)
instrumentation in future. Knowing the speed of a fan, the temperature of
a chip, or the voltage of a supply rail is more than just a gimmick - it
can be used to predict device failure...

ABS

-- 
                       Alaric B. Snell BEng ACGI
 http://www.alaric-snell.com/  http://RF.Cx/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software