On Thu, 3 Jun 1999, Alan Cox wrote:
> > Oh, and how do they install on the Sony VAIO, for example?
> > Hint: they don't. And PnP isn't the issue, never has been.
> 
> Some of it is. The hard questions being
> 
> "What irq is really free"
> "What dma is really free"
> "Give me some physical address space that isnt used"

What do you think about the following approach to this problem, using
the existing IO port allocation system as a base.

Use the existing resource table for IO ports, only have a new special
kind of entry with name=NULL, which means "occupied".  If a driver
calls check_region() and hits an occupied region, that call will
succeed.  Now, we take the Sparc occupy_region() call and make it
all-platform... and this call (which can fail, unlike request_region)
will strictly avoid conflicts with regions that have name==NULL.

Thus... check_region() will prevent driver-driver conflicts, as it
does now.  occupy_region() will prevent device-device conflicts, which
is compatible with its current usage on Sparc.

We can't use the "reserved" stuff for this since a "reserved" region
will return EBUSY on a call to check_region, and that has a different
purpose, to preventing probing of sensitive areas.

Now, we change release_region() to not actually free a region:
instead, it sets name to NULL.  This will be used (as it is now) for
all static device resources.  And we add a new vacate_region() call,
which indicates that a region can be allocated by another device.

So... request_region(), check_region(), release_region() will behave
as before for all devices that are not dynamically configured.  For
devices that are configured on the fly (are there others besides
PCMCIA and the Sparc stuff that already uses occupy_region?), they'll
use occupy_region() and vacate_region().  The code overhead and
changes to existing drivers should be minimal.

We can pre-populate the IO port table with name=NULL entries by
scanning the PCI bus, using the ACPI tables, or PnP BIOS calls, or any
combination.  Without doing any extra work, things will work as
before, but any info we can fill in will make dynamic allocations
safer.

(as an alternative to adding vacate_region(), we could add a flag to
the resource_entry_t structure to indicate if it described a static or
dynamic resource, and release_region would either set name=NULL or
free the entry based on this.  request_region() would be implicitly a
static allocation, and occupy_region() would be implicitly dynamic.  I
think this would be a waste, since a driver should always know which
to use)

Then, to extend to memory mapped devices, we add *_mem_region calls.
We can rearrange kernel/resource.c so that these share almost all
their code with the IO versions.

The same sort of approach (distinguishing between physically occupied
resources and resources associated with specific drivers) can also be
used for irq's, dma, etc: in each case, there would need to be a way
to "occupy" and "vacate" a resource.

Does this seem like a reasonable way to proceed?  I like it because it
doesn't introduce any API discontinuities.  Should I go ahead and
implement it?

-- 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/