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/