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/