From owner-freebsd-hackers Mon Jun 4 17:46:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.spock.org (cm-24-29-85-81.nycap.rr.com [24.29.85.81]) by hub.freebsd.org (Postfix) with ESMTP id A8AB237B401 for ; Mon, 4 Jun 2001 17:46:22 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F8823f550kLW08639F7T for hackers@FreeBSD.ORG; Mon, 4 Jun 2001 20:46:21 -0400 (EDT) (envelope-from jon) Date: Mon, 4 Jun 2001 20:46:21 -0400 From: Jonathan Chen To: hackers@FreeBSD.ORG Subject: Resource reservation idea Message-ID: <20010604204621.A2023@enterprise.spock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x 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 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