From owner-freebsd-current Sat Feb 15 22:33:42 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3035537B401 for ; Sat, 15 Feb 2003 22:33:41 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D4A443FBD for ; Sat, 15 Feb 2003 22:33:40 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 43819 invoked by uid 1000); 16 Feb 2003 06:33:42 -0000 Date: Sat, 15 Feb 2003 22:33:42 -0800 (PST) From: Nate Lawson To: "Matthew N. Dodd" Cc: current@FreeBSD.ORG, wpaul@FreeBSD.ORG Subject: Re: sys/pci/if* fixes In-Reply-To: <20030216011126.D73971@sasami.jurai.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Feb 2003, Matthew N. Dodd wrote: > On Sat, 15 Feb 2003, Nate Lawson wrote: > > The 'if' is a matter of coding style. Which is preferred: multiple > > returns from the same function (one which is only reachable from a goto) > > or one linear path with an 'if' to see if this is an error exit? > > In this case a single return is harder to read. I'm fine with going back to that style if someone else will corroborate this. One other advantage to the single return is that if a routine returns an error but this error is not checked, it will still be caught with my code whereas attach will return 0 unless code explicitly requests a failure. This is not a theoretical bug, many of the calls to bus_dma_tag_create() did not check for errors returned and would still return 0. However, this was never triggered due to that only happening on a very low memory condition. > > See the previous thread on this regarding my original dc(4) changes. > > It is bogus to create a lock with mtx_init and then immediately lock it > > for the entire attach routine just for the intention of ensuring > > exclusive access to the device. > > The problem is that the drivers aren't properly turning off interrrupts > before setting up the interrupt handler. This is on -current, turning off interrupts should be a very rare event. On -stable, I plan to only make the bugfixes in place since there is no locking to deal with. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message