Date: Mon, 21 Jul 1997 15:21:49 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: sound driver structure and configuration Message-ID: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707210352.FAA20510@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 05:52:10 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707210551.PAA21772>