From owner-freebsd-hackers Wed Jun 6 17: 1:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 951CC37B403; Wed, 6 Jun 2001 17:01:30 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f570BFB01284; Wed, 6 Jun 2001 17:11:15 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106070011.f570BFB01284@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: Nick Hibma , Mike Smith , Jonathan Chen , hackers@FreeBSD.ORG Subject: Re: Resource reservation idea In-reply-to: Your message of "Wed, 06 Jun 2001 10:55:27 MDT." <200106061655.f56GtRl00468@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jun 2001 17:11:15 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I appear to have missed some of this thread. Dang. > : > > - Some dummy driver which grabs the resource. The dummy driver would > : > > need to be unloaded when the actual driver needs the resources. > : > > : > This sounds attractive, but it's hard to find the dummy driver when > : > you want to open the bidding for one or more devices again. You also end > : > up with the ugly case where the device has more resources than the driver > : > uses; you end up needing a placeholder of some sort for these as well, so > : > you might as well just built it into the way the bus thinks about child > : > devices and be done with it. > : > : It was suggested some time ago to do this by having a priority value > : that indicates a dummy, say -10000. When a driver is loaded, all dummies > : are detached and the probe is restarted. The dummies are quiet if not > : cold booting to avoi a storm of dummies announcing themselves again and > : again. > > There are some subtle problems with this approach. Specifically, if I > have a card in a bus that can live at any address. I load a driver > for this card, so the bus reprobes. If all I have to go by is these > drivers that have reserved resources, then if we detach them all > before doing this, we could have a situation where order matters and > the device could get one of the other device's resources. Nick's point is that you only kick off the dummies. In reality, all this is bickering about is, "what is the container object for resources"? The approach that requires a dummy driver asserts that the container object is the driver instance. This is a much, much harder approach than asserting that the container object is the device instance. In practise, if you want a driver instance holding the resources, you have to do this: - create a device for every child on the bus. - attach drivers to as many children as possible. Force them to allocate *all* their resources, not just the ones they want (this is difficult). - attach a dummy driver to the rest of the children, and force it to allocate all the resources the child has. The second step is actually more common (and more irritating) than you think. It almost forces you to take the other approach anyway: - create a device for every child on the bus. - allocate all the child's resources and attach them to the device's ivars (using eg. a resource list). - attach drivers to children. When a child asks for a resource, just hand them the resource you've already allocated. I've coded this second approach, and it works well. Note that all of this is really only relevent to busses like PCI where the existence of a resource forcibly implies that it's enabled (with some special cases). With something like pccard where you can move the mapping windows around in the bridge, it's less of an issue. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message