Re: [RFC] Dropping Alpha sparse mapping support from X
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.