Messages in this thread | | | Date | Fri, 18 Jun 1999 15:48:12 -0700 | From | David Hinds <> | Subject | Re: More general resource allocation scheme: a patch to look at |
| |
On Fri, Jun 18, 1999 at 11:55:59PM +0200, Martin Mares wrote: > > o The resource table needn't be of a constant size. A linked > list of kmalloc'ed entries fits better.
I decided to leave it static, but changing to kmalloc would be simple enough and wouldn't affect the interfaces. I'm happy to do it or not.
> o Locking by cli/sti should be removed. Nobody needs to allocate > resources from interrupts :) It's probably enough to define > that these functions must be called with the big kernel lock held.
That was my first thought. But again I figured I'd leave the existing locking, and worry about that later: I'm more concerned with the API, and am indifferent to how the locking is done. In the PCMCIA code I've been using until now, I use a spinlock.
> o Leaving traces of the previously allocated region in release_resource() > needs more thinking about -- in case you load a driver with an incorrect > base address and then unload it because it doesn't work, the region > should disappear.
This is tricky. If the driver can tell that it has been loaded at the wrong address, then ideally, it should not register the resource in the first place (or it can use the vacate_* calls, if it figures out the problem after the fact). If the driver can't tell, then I'm not sure what other entity could make the decision about leaving the resource occupied or not. Maybe we just need to provide a way for the user to force a vacate.
Even if you do mis-probe and leave a bad entry in /proc/ioports, that should usually only be cosmetic. It will only cause trouble if there's some other not-yet-detected hardware with an overlapping but not identical resource, or if you happen to need that spot for a hot plug device.
> o We need to handle "not free, but allow requesting" regions (typically > space known to be occupied by a card, but not allocated by a driver yet).
This case is already handled by my patch: you get that by calling either request_resource() or occupy_resource() with name=NULL.
> Maybe we should look at track occupiedness and allocatedness as two > completely different attributes. This would look this way:
> check_resource() if ALLOCATED, fail > request_resource() set ALLOCATED > release_resource() reset ALLOCATED; if OCCUPIED not set, delete the region > occupy_resource() find !OCCUPIED && !ALLOCATED region > set OCCUPIED > vacate_resource() reset OCCUPIED; if not ALLOCATED, delete the region
This is *almost* how my patch works. The exception is that I assume that ALLOCATED implies OCCUPIED (i.e., I assume that drivers will not allocate resources for devices that don't exist, or if they do, that they'll know enough to vacate those resources when they're done).
I think that's a fair assumption to make. If a driver does allocate a resource and later decides it was a mistake, it can vacate it. A driver should never need to put a hold on a resource that genuinely is not occupied by any hardware, so I don't think we need to be able to support an "allocated && !occupied" state.
> This way we could gather information about all cards during bootup > (partly by scanning the bus as in PCI case, partly maybe by asking > the PNP BIOS -- Keith Owens was already experimenting with this), > be safe wrt. allocation of addresses for hotplug devices, but also > leave the old request/release semantics used in all the drivers intact.
That was exactly my plan... but by making the allocated->occupied assumption, we get better hot plug behavior even before the PCI, PnP, etc code to populate the tables is done.
-- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |