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/