> On Sat, Jul 17, 1999 at 09:12:29PM +0300, Alon Ziv wrote:
> > In my understanding of David's idea (I hope he'll correct me if I'm
> > wrong...), what he suggested was just that we use the same resource
> > manager internally by the various PnP support subsystems to maintain the
> > hardware hierarchies. The hardware hierarchies will be preallocated (if
> > needed); they may be used to route hotplug events, or to configure drivers
> > (if the drivers support this kind of `external cueing', which they _will_
> > need to do for proper PnP).
>
> I don't think so: I don't want the hardware tree to be internal to the
> PnP subsystem. It needs to be globally accessible: the "static" tree
> needs to have stuff put into it by PCI and PnP (and probably other
> things), and any hot plug subsystem needs to use it. I'm not really
> interested in using it to route hot plug events or manage driver
> bindings: I already have ways to do those things.
>
Hmm... I believe there's a misunderstanding on the term `static' here.
Linus uses `static' to describe the partitioning of space between the
various subsystems: eg plain (direct) PCI, ISA, PCMCIA &c. He says the
logical resource structure should still be partitioned according to these.
He also says these resources should be allocated on driver initialization
time (and not on device open or equivalent). I believe he's right.
David is using `static' mostly in the context of its relation to physical
hardware. As such, of course the resources are split by subsystem / bus /
whatever, but they are _different_.
So I still stand by my previous analysis: we need two trees (or actually
sets of trees)--- one is for logical resources (ioport / iomem / physmem /
virtmem / ...); the other is for physical properties of the system. The
logical trees are what's generally used by drivers; the physical ones are
mostly of interest to the various bus drivers, PnP subsystem, and hotplug
support code.
> I do think there are enough conceptual differences between the two
> sorts of resources, that two trees are conceptually sound, aside from
> the coding arguments. The "current" tree is, as Linus has also said,
> strictly to arbitrate the inb/outb and readb/writeb interfaces between
> different drivers. The "static" tree is to arbitrate hardware routing
> of regions of address space for different devices, and while it might
> seem convenient to overload these onto the same tree, conceptually,
> they are not really the same thing.
>
You're arguing my point. Just in different words.
To reiterate: the trees are _not_ describing the same resource. Not at
all. The existing trees describe resource allocations to drivers; the new
ones describe the resources provided by specific hardware (albeit in a
crooked fashion, where the resources are the index).
-az
------------------------+----------------------------------------------------
. __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel
------------------------+----------------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
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/