Date: Wed, 06 Jun 2001 10:55:27 -0600 From: Warner Losh <imp@village.org> To: Nick Hibma <n_hibma@qubesoft.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, Jonathan Chen <jon@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: Resource reservation idea Message-ID: <200106061655.f56GtRl00468@billy-club.village.org> In-Reply-To: Your message of "Tue, 05 Jun 2001 19:15:30 BST." <Pine.BSF.4.10.10106051912280.20600-100000@bluebottle> References: <Pine.BSF.4.10.10106051912280.20600-100000@bluebottle>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.10.10106051912280.20600-100000@bluebottle> Nick Hibma writes: : > > - 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. I also recall having a problem by not detaching all the devices at once, but I can't recall what it is at the moment. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106061655.f56GtRl00468>