From owner-freebsd-multimedia  Mon Jul 14 08:38:57 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA27303
          for multimedia-outgoing; Mon, 14 Jul 1997 08:38:57 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA27295
          for <multimedia@FreeBSD.ORG>; Mon, 14 Jul 1997 08:38:54 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id IAA04621;
	Mon, 14 Jul 1997 08:36:22 -0700 (PDT)
Message-Id: <199707141536.IAA04621@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Randall Hopper <rhh@ct.picker.com>
cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, multimedia@FreeBSD.ORG
Subject: Re: guspnp9 feedback 
In-reply-to: Your message of "Mon, 14 Jul 1997 06:26:02 EDT."
             <19970714062602.02401@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jul 1997 08:36:21 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

We can do a malloc during the attach and if that fails invalidate the 
driver via some flag in the sound driver.

	Cheers,
	Amancio

>From The Desk Of Randall Hopper :
> Luigi Rizzo:
>  |> As I said, it's not just the return type.
>  |> 
>  |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config
);
>  |> > void attach_awe_obsolete(struct address_info *hw_config);
>  |
>  |I have removed mem_start since the parameter was useless (just passed
>  |across functions) in all drivers I had seen, and only served to
>  |clutter the code.
> ...
>  |not change). The return type of the attach routine has been set
>  |(temporarily ?) to void since in the drivers I had seen attach()
>  |could never fail, nor it was generally tested for failute.
> 
> Thanks for the info Luigi.  
> 
> 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.
> 
>  |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
> take a stab (I've avoided these for obvious reasons).
> 
> Randall