Linus,
My suggestion to have two resource trees requires no changes to your
resource allocator code. It requires exporting two extra tree heads,
period. Everything that needs to use the second trees will know. You
pick my one minor example to jump on: sure, you're right, these
interface changes are not a big deal. I think they're gratuitous and
will cost more in code space than you save by having one tree, but
whatever. You ignore the other problems I described which are less
straightforward.
I'll describe, again, the central reason why I'd like to have this.
We would like to pre-allocate resources for all PCI and ISA devices so
that dynamic configuration can avoid conflicts with resources for
these devices, whether or not loaded drivers bother to register these
resources.
To do this, the PCI code and a future PnP subsystem will be populating
a resource tree with resource nodes for all system devices. If there
is one tree, then suddenly, all device drivers can't simply register
their resources from pci_io_resource and pci_mem_resource: they need
to find their nodes in the resource tree and register sub-resources of
those nodes. Hmmm. How do they do this? For PCI, we could tack lots
of resource pointers onto struct pci_dev, and it isn't a big deal,
though it requires updates to every driver. For ISA drivers, hmmm, we
don't have a device structure. How is an ISA driver supposed to
figure out what node(s) of the resource tree might belong to it?
The PCI and PnP code to populate the resource trees is written. I
wrote the PCI code and passed it to Martin a couple weeks ago, and I
have a tiny minimal PnP subsystem running on my own kernel. It all
worked with the old resource code. With the new code, I'm now faced
with having to fix all device drivers and invent a new way of managing
ISA devices, for the sake of saving two tree heads??
Also, I explicitly said that we could call this temporary, and unify
the trees down the road, when/if the driver interface changes are
done. It's simply a trivial, almost free, way of isolating the
changes from one another in the short term. If you can't see the
value of that, then I'm kind of at a loss.
Maybe I'm confused, but wasn't the original motivation for updating
the resource code to make hot plug support easier, not harder??
-- 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/