[RFC] Dropping Alpha sparse mapping support from X

Maciej W. Rozycki macro at linux-mips.org
Fri Sep 4 15:04:00 PDT 2009

On Thu, 3 Sep 2009, Matt Turner wrote:

> I'd like to drop support for non-BWX Alphas (EV4 and original EV5)
> from X. These machines can't load/store to single bytes and require
> special sparse memory mappings.
> The code required to select which functions (sparse, dense) is
> convoluted, adds an extra layer of indirection, probably gets close to
> zero usage, and even less testing.
> Does anyone use X on EV4 or EV5 (not EV56, EV56 has BWX)?

 What's the problem with making it a build-time option?  You may inline 
the indirection based on a macro or suchlike and keep the more complicated 
code for a reference, even if you don't get any bug reports for a while 
(perhaps the code is perfect? ;) ).  Linux is probably going to support 
pre-BWX machines as long as the Alpha port itself and you may have 
troubles reaching all the interested users, especially as not everyone 
makes frequent upgrades.

 Personally, I have planned to make the DEC 3000 AXP (that's the 
TURBOchannel family maxing out at EV45) Linux port going for a while now 
and will most likely get at it once I'm done with some VAX/Linux fiddling 
I'm currently involved with.  Linux already supports a number of 
TURBOchannel framebuffers for the MIPS port (for the purpose of 
DECstations), including but not limited to the SFB+ board which works with 
the TGA driver, and the drivers will work as soon as platform support code 
has been done -- there shouldn't be any platform-specific code left in the 
TURBOchannel drivers these days anymore.

 Once the kernel part has been done I expect the X11 side to be 
straightforward -- the DDX should work out of the box (for the DirectColor 
variations, that is; the PseudoColor variation of the SFB+ uses a 
different RAMDAC to that of its TGA counterpart, so it'll require some 
updates like the kernel driver did) as soon as you've got the address 
mappings sorted out.  Except that you need sparse addressing at least for 
the PseudoColor board.

 Just my opinion.


More information about the xorg-devel mailing list