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>