[RFC] Dropping Alpha sparse mapping support from X

Tiago Vignatti tiago.vignatti at nokia.com
Mon Sep 7 10:59:39 PDT 2009

On Mon, Sep 07, 2009 at 05:34:30AM +0200, Matt Turner wrote:
> Thanks for the responses, everyone.
> On Fri, Sep 4, 2009 at 6:04 PM, Maciej W. Rozycki<macro at linux-mips.org> wrote:
> > 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.
> After reading this and discussing it with a lot of people on IRC, I
> think you're right: a build time option probably is the best choice.
> Wrapping appropriate parts in #ifdef __alpha_bwx__ should do the
> trick, but would require binary distributions to provide two binaries.
> But since we might not have any binary distros with Debian exiting the
> alpha scene, this shouldn't be a problem.
> Thoughts?

Yep, makes sense for me.

We are already doing support for not conventional architectures on build time
and AFAIK there's no way to skip from having only one binary.


More information about the xorg-devel mailing list