lkml.org 
[lkml]   [1999]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.167 / U:4.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site