"Chris G. Demetriou" wrote:

Thanks for the feedback.  Your points are valid, which is
the main reason I'd like to have a way to easily have our
own sysctl interface :-).  I don't think they are generally
applicable.

I'll look at a device interface for misc control.  It would
touch the arch/mips less.  It was originally considered.

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

> a watchdog is, as far as I'm concerned, a device.

A device is a reasonable implementation, but a bit more complex.
We also have an LED device interface, but it is tied into some
other logic that makes it very machine specific. 

We could do a better job of abstracting that.

The main reasons we chose sysctl for misc functions were:
	- easy to implement misc functions.
	- easy to have multiple user mode compatible implementations
	  for different motherboards (we are already there).
	- ties in well with our platform code.
	- no need for a new command line interface.

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

Our watchdogging implementation will restart the system if upon
boot the embedded application does not start, and then start
correctly.

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

We could put the revision information in the hw.model.  To me
the hw.model is the high level name, and the boardinfo/revision
differentiates different HW revisions of the model.

> CPU_BOOT_ALTROOT serve?

In our system we maintain the current and previous software
release so the system can try new software before accepting
it.  It does boil down to a HW register write that the
firmware understands.  A reboot flag would be appropriate if
this were applicable to enough systems.

jeffs