below are my comments on your current choice of sysctls...

jeffs@geocast.com (Jeff Smith) writes:
> The sysctls we've added are:
> 
>         CPU_LED                 - controls system led

an LED is a device; it should have a device node, etc., associated
with it.


>         CPU_WATCH_PERIOD        - time between watchdog timeouts
>         CPU_WATCH_UPDATE        - update watchdog timer

a watchdog is, as far as I'm concerned, a device.  at least, when i've
had to implement them, they've been a device.  I plan to continue
implementing them that way.  8-)


>         CPU_APPL_START          - system application has started
>         CPU_APPL_OK             - system application is ok

it's ... not clear to me what exactly these are for, and/or why they
must be in the kernel...  can you provide more details?


>         CPU_DBGPROM             - prom type system is running.
>         CPU_BOOT_ALTROOT        - boot alternate / partition
>         CPU_BOARDINFO           - board revision information

These seem perhaps reasonable (though I don't think i get why
CPU_BOARDINFO is different than hw.model/HW_MODEL).

What purpose do the other two serve?  In particular, what purpose does
CPU_BOOT_ALTROOT serve?  if it's a on-time thing, it should probably
be handled with a reboot arg, rather than anything else, in my
opinon.  if it's a settable thing via the firmware, you should
probably have a 'device driver' that knows how to talk to your
firmware...


so, i guess, in a nutshell, i'm not even sure most of these should be
sysctls.


chris