Date: Wed, 06 Jun 2001 17:11:15 -0700 From: Mike Smith <msmith@freebsd.org> To: Warner Losh <imp@village.org> Cc: Nick Hibma <n_hibma@qubesoft.com>, Mike Smith <msmith@FreeBSD.ORG>, Jonathan Chen <jon@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: Resource reservation idea Message-ID: <200106070011.f570BFB01284@mass.dis.org> In-Reply-To: Your message of "Wed, 06 Jun 2001 10:55:27 MDT." <200106061655.f56GtRl00468@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106070011.f570BFB01284>