From owner-freebsd-multimedia Sun Jul 20 22:53:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA24584 for multimedia-outgoing; Sun, 20 Jul 1997 22:53:02 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24562; Sun, 20 Jul 1997 22:52:48 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA21772; Mon, 21 Jul 1997 15:21:49 +0930 (CST) From: Michael Smith Message-Id: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707210352.FAA20510@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 05:52:10 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 15:21:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > > The way to go for that (at the moment) is like the PCI code; you use a > > linker set to create an aggregated list of drivers, which you then > > scan with your bus code. > > more or less this is what I do now. Except that I do not leave the user > a choice of which modules to include and which not, and the actual > selection of the driver to use (if necessary at all) is done through > some bits of the 'flags' field. Ok. > I have done this because in in the sound driver there are probably a > couple of main operating modes (i.e. soundblaster and MSS) for the > codec, and all the card-specific code is for initialization or handling > special features of the board. And it is too complex to ask the user > (possibly an inexperienced one) to produce a correct configuration file > otherwise, with all the required options for his board. Aha. May I offer a suggestion? Have the 'snd' controller pull in all the modules for the various on-card subsystems. Have each of these subsystems register themselves in a linker set using a 'name' field to identify themselves. Then have 'device at ...?' statements which pull in probe code for each of the basic supported board types; eg. mss, sb16, etc. Each of these sets of probe code know how to find the board type they support, whether via PnP or direct probing, and then they use the linker set from the snd controller to locate the subsystem modules and feed them the information required to initialise the subsystems on the card. This lets you have board-specific probe and setup code, while keeping the driver components separate and board-independant. > > If using the PnP stuff is of interest to you, you could help me out > > with some suggestions for calling 16-bit protected-mode BIOS > > interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of > > unfortunately i am not enough familiar with the architecture of the > system to help out on this... Drat. 8) > Luigi -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[