Messages in this thread | | | Date | Sun, 18 Jul 1999 12:49:32 -0700 | From | David Hinds <> | Subject | Re: New kernel/resource.c |
| |
On Sat, Jul 17, 1999 at 09:12:29PM +0300, Alon Ziv wrote: > > > > The reason for two resource trees for the same resource would be that one > > would contain some kind of "static rules" resource description, and the > > other one would contain the "current setup" resource description. > > Everybody basically agrees that you _do_ need to have both.
It wasn't at all clear to me that you even agreed that we needed both. I'm glad we agree on that.
> 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.
Linus thinks one resource tree is the only way to go because we are conceptually describing a single resource. I think two trees are better, because the only parts of the kernel that care about the static info are hot plug bus drivers, and because putting this info in the same tree with the current info will be tricky. In an ideal world, it could be done cleanly because the static and current info would always be consistent with one another, and the static info would be complete. However, I know of enough exceptions, that I think the driver changes are not worth the effort. If someone comes up with a functionality argument for it down the road, they're free to do it. But it means the difference between a small job that I'd like to do to make PCMCIA work better, and a larger job that I won't do for no discernable benefit.
Actually, there is a way to merge the trees that would not require a lot of driver changes: instead of two trees, use two types of nodes, "bus" nodes, and "driver" nodes. The resource calls used by drivers would treat bus nodes as invisible: you could allocate a region already spanned by a bus node (and that would add a node below the bus node), and regions would appear "free" if they were only allocated by bus nodes. This is similar in spirit to what my 2.3.6 resource changes did. You would need two sets of resource functions, one for use by bus drivers implemented like the current calls, and a separate set for device drivers that would hide the bus nodes. I guess that's nearly isomorphic with the two tree implementation, with more code, so it doesn't really seem worth it to me. But it gives you one data structure per resource.
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.
-- 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/
| |