From owner-freebsd-current Sat Feb 15 21:52:41 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 D3F6237B401 for ; Sat, 15 Feb 2003 21:52:39 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9FBA943F85 for ; Sat, 15 Feb 2003 21:52:38 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 43768 invoked by uid 1000); 16 Feb 2003 05:52:38 -0000 Date: Sat, 15 Feb 2003 21:52:38 -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: <20030215092452.E73971@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 Sat, 15 Feb 2003, Matthew N. Dodd wrote: > On Fri, 14 Feb 2003, Nate Lawson wrote: > > Also, except for xl, all drivers have a common cleanup on error in > > attach that backs out allocated resources with no assumptions about the > > order they were allocated in. > > Please see if_pcn.c for the correct approach to freeing resources; its not > necessary to wrap evrything in 'if (sc && error != 0) {}'. If execution > reaches the 'fail' label then you assume that is what happened. 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? Regardless, the 'if (sc)' is necessary in ti.diff because the KLD_MODULE check at the beginning may goto fail before device_get_softc(). > I also think you should just drop and reaquire locks around the > bus_setup_intr() rather than moving code around. 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. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message