From owner-freebsd-multimedia Mon Jul 14 00:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05380 for multimedia-outgoing; Mon, 14 Jul 1997 00:20:43 -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 AAA05355 for ; Mon, 14 Jul 1997 00:20:26 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA10040; Mon, 14 Jul 1997 08:14:04 +0200 From: Luigi Rizzo Message-Id: <199707140614.IAA10040@labinfo.iet.unipi.it> Subject: Re: guspnp9 feedback To: rhh@ct.picker.com (Randall Hopper) Date: Mon, 14 Jul 1997 08:14:04 +0200 (MET DST) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG In-Reply-To: <19970713163210.43120@ct.picker.com> from "Randall Hopper" at Jul 13, 97 04:31:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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. I did not touch the awe driver since I wanted to talk to Randall first (and did not expect so much activity during this weekend, which I have spent on the beach playing with my son instead :) The intent is to remove mem_start from all attach routines. All relevent info can be supplied through hw_config if needed (perhaps we need to add some field to the structure, but the interface would 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. I do not think it is a particularly good idea to have attach() return void, but since there was no error checking anyways, I did it as a first cut. In the probe/attach sequence I notice that some drivers do call the probe() routine again in the attach(). This seems pointless since there should be no attach if the previous probe failed. 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. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________