From: Benjamin Herrenschmidt <bh40@calva.net>
Date: Wed, 21 Jun 2000 16:55:22 +0200
That would indeed be even better than the syscalls mecanism. Well,
at least we are now on a good path to a solution :)
Great.
There's one thing Egbert pointed me to: Some arch may require also
to be passed a "shift" information indicating a necessary shift on
the CPU addresses when mapping the PCI addresses. If I understand
Egbert correctly, than mean than an inb-like function would do
something like *((u8*)(addr << shift)), addr beeing the register
address in the card's space. This needs to be returned by this
driver (via another ioctl).
This would be a simple extension, so wouldn't be much of a problem.
Also, this driver could probably also handle read/writes so that
simple things that don't need specific performances can simply use
those functions and avoid having to handle the shift at all.
I would prefer such a facility is not added, mostly for the sake of
simplicitly. I have learned in the past that adding these sort of
little features can be a big maintainence pain in the end when it
really is not adding any new functionality which cannot be performed
already. The application will already have the power to perform what
this proposed feature will do.
Since, as you mention, there is no need for high performance in these
cases, it seems to also support the idea that the app should just
map/unmap the regions and perform the accesses itself.
Finally, we need an interface to PCI config accesses. My
understanding is that XFree remapping cards by doing direct config
accesses will harm hot- swap PCI and Cardbus dynamic assignement in
the kernel. This interface would allow the kernel to notice what's
going on.
I would say first off that XFree doing this itself is an accident
waiting to happen. The 2.4.x kernel has all of the infrastructure
necessary to properly assign resources to PCI devices.
So what I am saying is that I would rather the kernel provide and
interface which allows the application to say "Please assign the
base address registers of pci device bus/dev/fn" than to provide
a "Hey I just messed with the base address registers of this pci
device, go have a look at what I did and update your state, and hope
I didn't do anything wrong".
Let me give an example. What is to say that the XFree code knows what
restrictions exist to where PCI MEM space allocations can actually
take place? For example, on sparc64 PCI controllers, there is a
reserved range of the 32-bit MEM space which is interpreted as bus
mastering to main memory, so XFree would have to know to avoid this
area to operate properly on sparc64. The extents of this restricted
area are different depending upon which PCI controller is used, and on
some the range is even programmable so could be different on two
machines using the same controller chipset. The point here is that I
hope it is evident to someone reading this that this sort of
information has no place in an application, even one which is as low
level as the X server can be. The kernel already knows these details,
and this is my justification for not allowing applications to
themselves assign PCI resources.
I feel very strongly that Linus would agree with me on this point,
and that if he knew what XFree was doing wrt. PCI device resource
allocation, he would most likely scream :-)
I've just finished implementing alpha-like syscalls on my 2.2 PPC
tree, it's mostly a "proof of concept" for now, but your idea is
probably better.
Which syscalls are these? As a temporary solution I may wish to
do the same for sparc64 to get some of the PCI drivers to work
quickly.
Later,
David S. Miller
davem@redhat.com
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:22 EST