From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 6 18:29:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C3DB37B401 for ; Wed, 6 Aug 2003 18:29:04 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9B6343F93 for ; Wed, 6 Aug 2003 18:29:03 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h771SpFL038646; Wed, 6 Aug 2003 19:28:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 06 Aug 2003 19:27:42 -0600 (MDT) Message-Id: <20030806.192742.85412759.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20030807005810.GG35859@cicely12.cicely.de> References: <20030807001244.GF35859@cicely12.cicely.de> <20030806.183710.132444148.imp@bsdimp.com> <20030807005810.GG35859@cicely12.cicely.de> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: How to get a device_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 01:29:04 -0000 In message: <20030807005810.GG35859@cicely12.cicely.de> Bernd Walter writes: : The host bridge is not available yet at probing time of the host bridge. : What we have is the host bridges parent (nexus) in the calling function. : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or : we find it out later. Don't you mean legacy_pcib_is_host_bridge? That's where the matching is done in current right now (well, at least as of my last sync) If so, passing the host bridge's device down to it would be trivial to add. It would also allow other CPUs with builtin host bridges to do similar tricks to the one that is done for the ELAN. These sorts of features have been very common in other CPU families, and there's no reason to think that there won't be more of them in the x86 family as time goes on. I'm not sure that adding it to nexus at this stage of the boot would truly work. Since the legacy device has decided to attach, the nexus bus is already walking through its children. Adding a child during that walk strikes me as dangerous, since we have no locking on the children element of the device_t. Hmmm, looks I just found a source of problems in my newbus locking code that might explain some weird things happening when I enable it.... Thanks for making me go look :-) Warner