From owner-freebsd-current Tue Dec 15 04:16:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA21351 for freebsd-current-outgoing; Tue, 15 Dec 1998 04:16:42 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (goldfish.pht.co.jp [210.171.55.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA21346 for ; Tue, 15 Dec 1998 04:16:41 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id EAA05117; Tue, 15 Dec 1998 04:14:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812151214.EAA05117@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: Mike Smith , current@FreeBSD.ORG Subject: Re: PAO Integration? In-reply-to: Your message of "Mon, 14 Dec 1998 23:49:37 MST." <199812150649.XAA02978@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Dec 1998 04:14:26 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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