Date: Mon, 4 Jun 2001 20:46:21 -0400 From: Jonathan Chen <jon@FreeBSD.ORG> To: hackers@FreeBSD.ORG Subject: Resource reservation idea Message-ID: <20010604204621.A2023@enterprise.spock.org>
next 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.
- Some dummy driver which grabs the resource. The dummy driver would
need to be unloaded when the actual driver needs the resources.
What I propose is this -- implement a new set of bus functions
bus_reserve_resource(), with the following parameters:
device_t parent,
device_t bus,
int type,
u_long start,
u_long end,
u_int flags
[I don't believe a resource id is necessary or desirable. Consider the
case where a child might reserve a range in the middle of what the
parent has reserved, thereby splitting the original reservation into
three, rendering the rid's messed up.]
The core functions can be implemented at the nexus level with the default
function passing the hat to its parent. The nexus reserve functions would
have the following properties:
- If resource specified is free, reserve it to the bus.
- If resource specified is (partially) allocated/activated by anything
other than the bus's immediate child, return error.
- If resource specified is (partially) already reserved, and
- requested resource is completely reserved to any parent, change
reservation to new device.
- otherwise, fail.
One flag might be RF_DEFAULT_RANGE, where child devices to that bus with
automatically try to use something within that range if the resource
range is not explicitly specified.
bus_unreserve_resource() would simply remove the reservation for all
resources within the specified range that is reserved to the bus,
regardless of whether the resource is currently allocated. It would
have the following parameters:
device_t parent,
device_t bus,
int type,
u_long start,
u_long end
There would also need to be changes in the nexus alloc_resource()
functions, as follows:
- If resource range is not explicitly specified, try allocation within
default range. If entire resource does not fit, try fitting as much
as possible.
- If resource range is explicitly specified, check if any portion of
the resource is reserved. If any portion of the resource is reserved
to anything other than the device's immediate parent, return error.
The proposed changes above should not require changes to existing bus
codes to maintain compatibility. Only minimal changes should be
required to take advantage of this.
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.
Please comment on the necessity, portability, interface, functionality
(or whatever else you can think of) of what is described here. If all
goes well, I hope to have some initial implementation in not too long.
On a side note, I just thought of something -- should PCI bus numbers be
treated as a resource too?
--
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
\\\_\ Jonathan Chen jon@freebsd.org /_///
<____) No electrons were harmed during production of this message (____>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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?20010604204621.A2023>