Date: Mon, 14 Jul 1997 08:36:21 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback Message-ID: <199707141536.IAA04621@rah.star-gate.com> In-Reply-To: Your message of "Mon, 14 Jul 1997 06:26:02 EDT." <19970714062602.02401@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707141536.IAA04621>