Subject: Re: port specific machdep sysctl definitions
To: None <>
From: Simon Burge <>
List: port-mips
Date: 07/12/2000 11:03:29
Jeff Smith wrote:

> All:
> Our product at geocast has a number of specific sysctls we use for
> tweaking things that are part of the main platform code.  They don't
> really belong in a driver.  Using sysctl is also great as it allows
> them to be accessed from the command line.
> Last night I changed mips/include/cpu.h to not define the machdep
> sysctl defines if they have already been defined by machine/cpu.h.

Ignoring Chris' issues on what the contents of the sysctl's themselves
are, I'll throw a different possible solution.

If you don't need sysctl(8) support to display the sysctls by name
and list all sysctls in the CPU mib (which is doubtful in an embedded
application) and just want to call the sysctls from application
programs, then you can just define your own CPU_* sysctls and handle
them in cpu_sysctl().  There's nothing in the kernel that actually
checks the value of CPU_MAXID.

> This seems fairly clean to me.  The big problem is if you touch
> use this feature you break binary compatability (sysctl command,
> potentially other commands that use sysctl) with other like
> endian MIPS ports.
> For our concern, this doesn't bother us, but I can see how it
> would bother other mips users working on multiple platforms.
> I'm looking for others opinions on how to handle this.  As I see
> I can:
>         1) Leave it as is, with an additional comment that if you
>            override you will not be user land compatible.
>         2) Add our sysctls to the mips cpu.h.  Ports that do
>            not use them will not implement them.  This is
>            what Simon Burge requested.
>         3) Live with merging this file in geocasts tree.  We
>            are really trying to sync up so we can participate
>            more.

At first I thought that you were planning on adding port specific
sysctls to an existing NetBSD port.  Certainly I don't want to make it
harder for non-NetBSD (wrong phrase but you know what I mean) users.

Will the above solution work for you?  Other than that, (1) is probably
the next best thing.

The best solution is to have a dynamic sysctl intrastructure.  There's
been some ideas floating around but it's obviously not going to happen
too soon...