From owner-freebsd-multimedia Mon Jul 14 03:52:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA13435 for multimedia-outgoing; Mon, 14 Jul 1997 03:52:06 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA13370 for ; Mon, 14 Jul 1997 03:51:38 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA10489; Mon, 14 Jul 1997 11:44:29 +0200 From: Luigi Rizzo Message-Id: <199707140944.LAA10489@labinfo.iet.unipi.it> Subject: Re: guspnp9 feedback To: rhh@ct.picker.com (Randall Hopper) Date: Mon, 14 Jul 1997 11:44:29 +0200 (MET DST) In-Reply-To: <19970714062602.02401@ct.picker.com> from "Randall Hopper" at Jul 14, 97 06:25:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Ok, well the awe driver mallocs kernel mem in the attach. If the malloc > fails, it returns 0. Since attach() calls can fail, it might be good to > leave the non-void return type in there, and we can beef up the error > checking of attach() invocations as we notice unchecked invocations. see one of my followup messages (also to hackers) on the failure handling in attach routines. I will have to read the bible (the daemon books on 4.3 and 4.4) to see what is the best way, but it currently seems easier to put all things which might fail into the probe routine. > |Also, the probe code can probably benefit from the addition of proper > |support for PnP boards, since these boards identify clearly themselves > |in the PnP id and do not require black magic in the probe routine. > > Good point. There's some PnP detection code for the SB32/AWE32 cards in > newer versions of the Linux AWE driver, but later versions are GPLed. So I > guess this would have to be reengineered (?). If I had a PnP card, I'd the sound_pnp.c file has some pnp code inside. Perhaps even the gus files. Finally, I have a (locally patched) copy of the pnp code from S.Patel which can be used to this purpose. So we do not really need to rewrite any low-level pnp stuff, just integrate pieces. With sound cards, I still have a conceptual problem, since one card can have multiple etherogeneous "devices" (e.g. audio, midi, synthesis) at different addresses. I will have to look more carefully at the pci code to see if/how it can deal with multifunction devices, and then will duplicate their approach for PnP. One more problem is that many of the sound files do not support multiple instances of one device, they use static variables for each device type. Cheers Luigi