Messages in this thread | | | Date | Thu, 15 Jul 1999 14:58:23 -0700 | From | David Hinds <> | Subject | Re: New kernel/resource.c |
| |
On Thu, Jul 15, 1999 at 11:14:54AM -0700, Linus Torvalds wrote: > > You can have an arbitrary number of trees inside the PCMCIA code. One of > the goals I had was to never EVER care about what the resoruce allocators > were actually used for, and you can have "private" resources inside > PCMCIA.
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/
| |