From owner-freebsd-multimedia  Sun Jul 13 16:06:17 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id QAA12260
          for multimedia-outgoing; Sun, 13 Jul 1997 16:06:17 -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 QAA12255
          for <multimedia@FreeBSD.ORG>; Sun, 13 Jul 1997 16:06:14 -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 QAA00971;
	Sun, 13 Jul 1997 16:06:11 -0700 (PDT)
Message-Id: <199707132306.QAA00971@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Randall Hopper <rhh@ct.picker.com>
cc: multimedia@FreeBSD.ORG
Subject: Re: guspnp9 feedback 
In-reply-to: Your message of "Sun, 13 Jul 1997 18:56:09 EDT."
             <19970713185609.15629@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 13 Jul 1997 16:06:10 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


We have a little disconnect here since it is Luigi who took out mem_start
so I am force to wait for him to answer back and I have no clue
why he decided to turn the attach routine from long to void.
Can you try out the driver to see if it can uncover other problems
while we wait for Luigi?

	Tnks,
	Amancio


>From The Desk Of Randall Hopper :
> Amancio Hasty:
>  |Luigi took out the mem_start since it was not been used. 
>  |Have you try out guspnp9 with your awe?
> 
>  |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config
);
>  |> > void attach_awe_obsolete(struct address_info *hw_config);
> 
> 
> No, I hadn't.  That was the purpose of the first message in this thread; to
> let you guys know about compile problems and the change that wasn't flowed
> everywhere.
> 
> As to the apropriate fix for this:  this routine currently returns a
> pointer to its malloced sample memory if successful, and 0 if not.  Is it
> now assumed that the malloc will always succeed?  Or should the malloc move
> someplace else based on the redesigns you and Luigi are doing?
> 
> Randall
>