Re: [RFC] Dropping Alpha sparse mapping support from X

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-6z/[email protected]> 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.

            Tiago