Date: Mon, 04 Jun 2001 18:58:48 -0700 From: Mike Smith <msmith@freebsd.org> To: Jonathan Chen <jon@FreeBSD.ORG> Cc: hackers@FreeBSD.ORG Subject: Re: Resource reservation idea Message-ID: <200106050158.f551wmL06759@mass.dis.org> In-Reply-To: Your message of "Mon, 04 Jun 2001 20:46:21 EDT." <20010604204621.A2023@enterprise.spock.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Currently on FreeBSD, resources are either free, allocated or activated.
> As I understand it, they mean approximately the following:
> - Free: unused.
> - Allocated: Resource reserved for use by device X.
> - Activated: Resource actively used by device X.
>
> This leaves somewhat of a gap. What if bus Y wants to reserve some
> resource for an attached hardware, but the driver of the hardware does
> not exist (yet)? Currently, I can think of two ways this can be done:
> - Have the bus allocate the resource, then hand it off to the child
> if/when it requests it. From my experience with cardbus, this can
> get messy and each bus has to implement its own resource management.
This is how I'm doing it in the new PCI code; since PCI devices actually
have these resources assigned whether a device happens to be using them
or not, this is a good match.
With Cardbus, you should be allocating the resources when the card
arrives, then hand them off to the driver, and release them when the card
goes away.
This model works quite well; a resource is typically either extant and
decoded, or not extant at all. The grey cases are already reasonablly
well handled (multiple ownership, allocated vs. active, etc.)
Resource lists make handling this fairly easy.
> - 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.
> What I propose is this -- implement a new set of bus functions
> bus_reserve_resource(), with the following parameters:
I don't see that these are actually necessary. The current model works
just fine.
> An alternative to this system is to provide some interface to easily
> hand-off resources from a bus to its child. While this will work for
> most cases, it does not provide functionality for a case where a bus
> might want to reserve a range to eventually dish out to various
> different children.
Typically, a bus isn't going to "reserve a range" in the fashion you
describe. It should just request the resources it wants, and let the
bridge above it (and potentially the series of bridges above it) sort out
what range(s) are appropriate. In most cases, a bus really isn't going
to know in advance what sort of resources it might need to assign to its
children, so second-guessing will lead to suboptimal behaviour.
> On a side note, I just thought of something -- should PCI bus numbers be
> treated as a resource too?
Yes; at least, a PCI device should be able to request a PCI bus number
range. This is necessary for configuring unconfigured PCI:PCI bridges.
--
... 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?200106050158.f551wmL06759>