Messages in this thread | | | Date | Wed, 14 Jul 1999 12:08:23 -0700 | From | David Hinds <> | Subject | Re: New kernel/resource.c |
| |
On Tue, Jul 13, 1999 at 09:23:00AM -0700, David Hinds wrote: > > In principle, I like the heirarchical arrangement because it is > "right", but since we have no infrastructure for communicating > resource information between bus drivers and device drivers, it > doesn't look like there is any way for me to use this capability > without significant driver updates.
Thinking about it some more, the only way I see to handle all the problem cases I can think of, is to have two separate resource trees for each type of resource, one for driver ownership, and one for hardware routing, rather than one unified tree. So we'd have two trees like:
- driver IO: 0-0xffff - keyboard: 0x60-0x6f - lp1: 0x378-0x37a - hdc: 0x100-0x107 - hdc: 0x10e-0x10e - eth0: 0x2000-0x20ff - eth0: 0x2100-0x21ff
- hardware IO: 0-0xffff - ISA dev 00: 0x60-0x6f - ISA dev 01: 0x378-0x37b - PCMCIA socket 0: 0x100-0x10f - Cardbus bridge window 0: 0x2000-0x21ff - PCI dev 2.00 base 0: 0x2000-0x20ff - PCI dev 2.00 base 1: 0x2100-0x21ff
This avoids the problem of defining a new API for passing resource information to device drivers: they can just manipulate the driver resource trees. The hardware tree will be populated by bus drivers: the PCI subsystem, PnP, PCMCIA/CardBus, etc.
-- 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/
| |