Messages in this thread | | | Date | Mon, 7 Jun 1999 09:22:31 -0700 | From | "David S. Miller" <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
Date: Mon, 7 Jun 1999 17:30:58 +0200 (CEST) From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
But at least offb (the Open Firmware frame buffer device driver we use for boards without a real driver) should have a big endian fbcon-cfb8 since OF provides a big endian frame buffer only. On most other boards we could use the little endian aperture.
Ok, I understand this.
The situation is special, and thus you can do special things in that driver. But it really does not advocate a generic mechanism being available to deal with this. Can we agree on this point?
You can say `doh, {read,write}l() should test for the addresses and behave different for Zorro and PCI' (either through explicit tests or through (yuck) function pointers), but you don't really want that overhead for the text console, do you?
Function pointers are not so ugly actually, but they do cost something, I agree.
And on systems where the mentioned setup cannot exist (or is the _only_ setup can exist), you can optimize away the function pointers at kernel compile time, right? We do a lot of this already actually. And actually on m68k systems you probably want the smallest most specific kernel possible, so my suggested scheme would work out for most people using such systems right? They'll say "hey I have Zorro, and I have one of these PCI frame buffers, and no others" when they configure their kernel.
Also keep in mind that mechanisms like Jakub's boot time fixup relocation hacks on Sparc can be made a generic kernel feature, and in such a framework you'll win in all cases, ie. genericism at zero cost, where you need it.
The core of all my arguments is that a genericized interface or mechanism should not exist _purely_ to handle %1 of real life configurations. This is why Solaris DDI/DK and friends are the way they are, general to the point of significant unnecessary overhead for %99 of the real world.
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/
| |