Subject: Re: port specific machdep sysctl definitions
To: Chris G. Demetriou <>
From: Jeff Smith <>
List: port-mips
Date: 07/11/2000 12:08:12
"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

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

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


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.