Hmmm, I'm afraid you've lost me here. Resources on different busses
go in different resource trees? It seems to me that host processor
address space is the most fundamental resource to be arbitrated. How
do we do that, if each bus is kept track of separately?
> No. There is one kind of resource - the one from the perspective of a
> driver. Anything else is irrelevant.
Well, I guess it's hard for me to argue if you believe the perspective
that matters to me is irrelevant.
> The Linux way of accessing PCI is though inb/outb() and readb/writeb()
> interfaces. The "pci_io_resource" and "pci_mem_resource" protect those
> interfaces, and nothing else.
You've lost me again. inb/outb and readb/writeb are not PCI specific,
so how can they be arbitrated using a PCI-specific resource tree?
> If you have code that reliably fully enumerates the hardware, then we'll
> look at that code and start changing drivers. Backwards compatibility is
> evil if it results in things that do not make sense.
I doubt that the code to enumerate hardware will ever be reliably
complete, due to the nature of PC hardware. It will only ever be a
90% (or 95%, or 99%) solution to the problem. I think we can only
hope it to be usually good enough.
Gratuitous disregard for backwards compatibility is also evil. You
should be able to point to real costs (time, space, complexity), not
just assert that something doesn't meet your impression of semantic
cleanliness. In this particular case, I think my solution wins on the
objective measures. I think I'm a fairly sensible person and it makes
sense to me, independent of the compatibility issues. You can place
whatever value you wish on that judgement; I'd guess not much.
-- 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/