Why is this, or should this, be any different from SES stuff which does the
same thing.


> 
> 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
> 
>