From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 12:24:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D6E1065670 for ; Wed, 10 Jun 2009 12:24:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6338FC13 for ; Wed, 10 Jun 2009 12:24:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1959246B2E; Wed, 10 Jun 2009 08:24:30 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 04F5F8A06A; Wed, 10 Jun 2009 08:24:29 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 10 Jun 2009 08:22:15 -0400 User-Agent: KMail/1.9.7 References: <20090609.174249.-1435625969.imp@bsdimp.com> In-Reply-To: <20090609.174249.-1435625969.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906100822.15516.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 08:24:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: devclass_find_free_unit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:24:30 -0000 On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: > What purpose does devclass_find_free_unit serve? I think it can safely be > eliminated from the tree. The current design is racy. > > Comments? > > It is currently used: > > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: devclass_find_free_unit(ata_devclass, 0)); > > # All the above can be replaced with a simple '-1'. > > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) == NULL) { > > These can likely be replaced by '2', but that may result in a warning > message being printed that likely can be eliminated... ata does this so it can reserve ata0 and ata1 for the "legacy" ATA channels on legacy ATA PCI adapters. That is, if you have both SATA controllers and a PATA controller, this allows the two PATA channels to always be ata0 and ata1 and the PATA drivers to always be ad0 - ad3. You could perhaps implement this in 8.x now by a really horrendous hack of having ISA hints for ata0 and ata1 and letting bus_hint_device_unit() in the atapci driver claim those hints for the channels on PATA controllers. -- John Baldwin