Messages in this thread | | | Date | Fri, 18 Jun 1999 23:55:59 +0200 | From | Martin Mares <> | Subject | Re: More general resource allocation scheme: a patch to look at |
| |
Hi,
> Let me know what you think of this patch. I obviously can't test all > drivers for weird interactions, but it seems to do the right things on > my system, with normal drivers and with tweaked PCMCIA drivers. I > figure we should first set up this infrastructure (and see if it > causes any problems), then later, we can update things to populate the > memory map.
Your changes IMHO in the right direction, but it would be better to change the resource management code even more:
o The resource table needn't be of a constant size. A linked list of kmalloc'ed entries fits better. 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. o There should be also a kernel option for reserving memory, not only I/O. 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. 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). 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 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.
Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "IBM = Inferior, But Marketable"
- 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/
| |