We are obviously not communicating. I sat down and wrote out another
example of what I've already explained twice already, and I don't see
how it would be any more clear than what I've already said.
I want PCI and PnP code to preallocate resources for all hardware
regardless of what drivers are loaded. I have code that does it. I'm
not willing to rewrite the resource code in every driver in the kernel
to make that work, when there is no need or benefit to doing so. Tell
me how this information goes into the "one tree" in a way that PCMCIA
can use it, without messing up anything else. With a separate tree
for this information, it is trivial. I'm just taking all these new
nodes that drivers won't care about anyway, and putting them someplace
else.
I see it as giving me 100% of what I want for 10% of the effort and no
API changes. You say "one kind of information, one tree, period." If
that's what you want, I guess that's the end of the argument.
> My point is that there is one PCI resource, and that implies that there is
> just one resource tree for PCI. Simple logic.
The names "pci_io_resource" and "pci_mem_resource" should really be
changed to be non-bus-specific, because they are not just PCI
resources. I'd also disagree with your logic, because there is one
set of resources from the perspective of hardware (i.e., a tree that
represents how transactions are propagated after they leave the CPU),
and one from the perspective of software (i.e., a tree describing how
drivers interact with regions of CPU address space). The two can
largely be superimposed, but you're representing two fundamentally
different kinds of information.
To give one example (there must be others), for some PCMCIA devices,
the PCMCIA bus driver constructs an IO region by concatenating several
bridge IO windows with different functional properties. From the
hardware perspective, there are several IO resources in play: the
windows can be configured and released independently. A client driver
"sees" this as, functionally, just a single block of ports. How
should this be represented in the resource tree? Does the client
driver need to know that its one contiguous IO resource was actually
implemented in a more complicated way by the low level hardware?
-- Dave Hinds
-
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/