Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Dec 1998 04:14:26 -0800
From:      Mike Smith <mike@smith.net.au>
To:        Warner Losh <imp@village.org>
Cc:        Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG
Subject:   Re: PAO Integration? 
Message-ID:  <199812151214.EAA05117@dingo.cdrom.com>
In-Reply-To: Your message of "Mon, 14 Dec 1998 23:49:37 MST." <199812150649.XAA02978@harmony.village.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199812132321.PAA00350@dingo.cdrom.com> Mike Smith writes:
> : Drivers should export a set of options that are a union of the set of 
> : options the driver supports plus a subset of the options for a device 
> : provided by the bus.  This can be determined by examining the driver 
> : and bus data at probe/attach time; something that's easy with KLD/
> : newbus/loader, but would require a bolt-on for newconfig.
> 
> A sysctl-like mechanism would likely be a good idea.  Let me explain
> what I have in mind.

More to the point, this is configuration information, so it lives in 
parameter space.

> First, let us say that there are configuration files.  Let us say
> these files use the sysctl syntax.  Let us further suppose that we
> extend the sysctl notation to include wild cards.  We'd have something
> similar to the xdefaults (xrdb actually) syntax.  This sparse database
> would be kept around.
> 
> When modules are initialized (either as being part of the base system,
> statically linked in, or when dynamically loaded by some means), the
> sysctl's variables are set (if they match this sparse database).
> 
> Now, this would allow drivers and other modules to be dynamically
> configured in a user friendly manner.  The "sparse database" would
> allow for the user to specify things (eg the band for a radio modem,
> the video signalling to use (ntsc vs pal), etc).

Yup; this all matches more or less what I was thinking so far...

> Some examples:
> 
> driver.aha*tune_bus: 1
> driver.bt848*video_format: ntsc
> 
> When the aha driver starts, it registers the sysctl variable
> 
> driver.aha.unit0.tune_bus
> 
> and then finds its value.  Since it matchces the above sepecification,
> it will have a value of 1 when the driver checks its value.

I think you've tangled a couple of different ways of getting at the 
data there, but I think that's fairly close.  

You've only used two uniquifiers, the driver name and instance number, 
but I'm wondering whether we might not want to support a more general 
mechanism where you can specify other uniquifiers for the match.

eg.

  driver=sio, bus_attribute=removable: powerup_on_open=yes

This may also be an instance of feeping creaturism...

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812151214.EAA05117>