[RFC] Dropping Alpha sparse mapping support from X

[Matt Turner-3]

Hi,
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)?

Thanks,
Matt Turner


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lennart Sorensen]

On Thu, Sep 03, 2009 at 05:08:00PM -0400, 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)?

Well I have a few EV56's, so those are fine.  I think one machine I have
is an EV5 or maybe even an EV4, but it only has 32MB of ram so it is
totally useless as debian can't run on it.

So I personally wouldn't notice the change.  Anyone else out there?

--
Len Sorensen


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bob Tracy]

On Thu, Sep 03, 2009 at 05:25:29PM -0400, Lennart Sorensen wrote:

> On Thu, Sep 03, 2009 at 05:08:00PM -0400, 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)?
>
> Well I have a few EV56's, so those are fine.  I think one machine I have
> is an EV5 or maybe even an EV4, but it only has 32MB of ram so it is
> totally useless as debian can't run on it.
>
> So I personally wouldn't notice the change.  Anyone else out there?

Got a PWS 433au: EV56.  Proposed change would have no impact here.

--
------------------------------------------------------------------------
Bob Tracy          |  "Every normal man must be tempted at times to spit
rct@...       |   upon his hands, hoist the black flag, and begin
                   |   slitting throats." -- H.L. Mencken
------------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Alan Hourihane-4]

On Thu, 2009-09-03 at 21:50 -0500, Bob Tracy wrote:

> On Thu, Sep 03, 2009 at 05:25:29PM -0400, Lennart Sorensen wrote:
> > On Thu, Sep 03, 2009 at 05:08:00PM -0400, 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)?
> >
> > Well I have a few EV56's, so those are fine.  I think one machine I have
> > is an EV5 or maybe even an EV4, but it only has 32MB of ram so it is
> > totally useless as debian can't run on it.
> >
> > So I personally wouldn't notice the change.  Anyone else out there?
>
> Got a PWS 433au: EV56.  Proposed change would have no impact here.

I do have a Multia (21066 CPU) with the 21030 graphics chip which was
used to write the DEC TGA driver, so we'd lose that, but I'm not sure
how many people are still using the TGA's.

Alan.


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[danielf]

Alan Hourihane escribió:

> On Thu, 2009-09-03 at 21:50 -0500, Bob Tracy wrote:
>> On Thu, Sep 03, 2009 at 05:25:29PM -0400, Lennart Sorensen wrote:
>>> On Thu, Sep 03, 2009 at 05:08:00PM -0400, 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)?
>>> Well I have a few EV56's, so those are fine.  I think one machine I have
>>> is an EV5 or maybe even an EV4, but it only has 32MB of ram so it is
>>> totally useless as debian can't run on it.
>>>
>>> So I personally wouldn't notice the change.  Anyone else out there?
>> Got a PWS 433au: EV56.  Proposed change would have no impact here.
>
> I do have a Multia (21066 CPU) with the 21030 graphics chip which was
> used to write the DEC TGA driver, so we'd lose that, but I'm not sure
> how many people are still using the TGA's.
>
> Alan.
>
>

We only have ev56's(1) and ev6's(4) so no problem.
Thanks.

--
-----------------------------------
    Daniel Franganillo Corrales
-----------------------------------
e-mail: danielf@...
-----------------------------------
CriptoLab. Despacho 6305.
Facultad de Informática.
Campus de Montegancedo S/N
Universidad Politécnica de Madrid.
Boadilla del Monte. Madrid (Spain)
Teléfono - 91 336 (3673)
-----------------------------------

[Gianluca Bonetti]

2009/9/3 Matt Turner <mattst88@...>:

> Hi,
> 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)?

Hi
I think that EV4 machines are too slow to handle the workload of a
current Linux distribution, so we should be happy with what we have.
I have some EV4 workstations and know that well.
It is a shame for EV5 machines which have still a chance to run new
software decently, but again, we should be happy with what we have.
So, for me, you could drop non-BWX support if it means continuing to
support X on newer Alphas!

Bye
gl


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bob Tracy]

On Fri, Sep 04, 2009 at 09:02:57AM +0100, Alan Hourihane wrote:

> On Thu, 2009-09-03 at 21:50 -0500, Bob Tracy wrote:
> > On Thu, Sep 03, 2009 at 05:25:29PM -0400, Lennart Sorensen wrote:
> > > On Thu, Sep 03, 2009 at 05:08:00PM -0400, 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)?
> > >
> > > Well I have a few EV56's, so those are fine.  I think one machine I have
> > > is an EV5 or maybe even an EV4, but it only has 32MB of ram so it is
> > > totally useless as debian can't run on it.
> > >
> > > So I personally wouldn't notice the change.  Anyone else out there?
> >
> > Got a PWS 433au: EV56.  Proposed change would have no impact here.
>
> I do have a Multia (21066 CPU) with the 21030 graphics chip which was
> used to write the DEC TGA driver, so we'd lose that, but I'm not sure
> how many people are still using the TGA's.

I've got a working TGA I can use for testing if push comes to shove, but
I replaced it with a Radeon RV200 QW [Radeon 7500] ages ago.  Wouldn't
use the TGA again except as a last resort: truly a case of "bad breath
is better than no breath."

--Bob


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jeff Donsbach-3]

I'm just curious..... where is the problem code in question?

You should Cc "gentoo-alpha@..." too in case anyone over there might care (I would have since I was running Gentoo on mine at one time).


-----Original Message-----
From: Matt Turner <Matt%20Turner%20%3cmattst88@...>
Reply-to: Linux on Alpha processors <axp-list@...>
To: xorg-devel@... <%22xorg-devel@...>, debian-alpha@... <%22debian-alpha@...>, Linux on Alpha processors <Linux%20on%20Alpha%20processors%20%3caxp-list@...>
Subject: [RFC] Dropping Alpha sparse mapping support from X
Date: Thu, 3 Sep 2009 21:08:00 +0000

Hi,
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)?

Thanks,
Matt Turner

[Maciej W. Rozycki]

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.

  Maciej


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Lorenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Sep 4, 2009, at 6:04 PM, Maciej W. Rozycki 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.

Same with NetBSD, we will probably support these machines as long as  
anyone can be arsed to play portmaster.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSqLrgcpnzkX8Yg2nAQK1EQf/f7HXBki5+j28VFdk8BloZbme+p4TtQgY
jXwkwB5rP64Lu7XQjYpH0hJsB8rE4ELqSP85R2j4kmKNOMFuUsVFPKUOlMCn/6hn
6nyEnuIt/G9ic/3p66Bu9H0Rb9X8JGkVpvWO6hSGg3Ir2A5X+8h8wsyJk2OqZCLM
kZHbeZXDkMjMtmh2wcpLpDqBXhKKWTQajPObPbaUaPsDnDMnNO0jIsb/dzcPXyrM
x/YlHdq6ch5ej0x5lRNq1vnlzI82X5zoxGUiC37jYNgL7u1K36zhPJgLAPi5oeDx
K2GQRyWuD5poxBDw3yfQ+iUbjNzKC8hD86AU+vfHqXlSlqT+in7NtA==
=JA23
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Robert Oram]

Hi,
        I only have EV56's or newer, so it won't affect me.  I always hate
to see support dropped for legacy hardware, but since I can't take over the
support myself, I guess I can't complain much!

Bob

-----Original Message-----
From: Matt Turner [mailto:mattst88@...]
Sent: Thursday, September 03, 2009 5:08 PM
To: xorg-devel@...; debian-alpha@...; Linux
on Alpha processors
Subject: [RFC] Dropping Alpha sparse mapping support from X

Hi,
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)?

Thanks,
Matt Turner


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact
listmaster@...



--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Turner wrote:

> Hi,
> 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)?

My Alpha is an EV56.  I had not booted it for 480 days, so it wouldn't
really have mattered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqkfrQACgkQX1gOwKyEAw9FDACdEv1stZ9nF0tVWb+LCCaVNtoY
7VAAn2r5HwNb7Py8Zlj1gCdez1mek3zY
=0X2W
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matt Turner-3]

Thanks for the responses, everyone.

On Fri, Sep 4, 2009 at 6:04 PM, Maciej W. Rozycki<macro@...> 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?

>  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.

On a different note, I've got a VAX 4000 model 60 I could use to help,
when you get that far.

Thanks,
Matt Turner


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tiago Vignatti-4]

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@...> 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


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Bouyer]

On Sat, Sep 05, 2009 at 06:51:45PM -0400, Michael wrote:
> Same with NetBSD, we will probably support these machines as long as  
> anyone can be arsed to play portmaster.

I'd also add that the Xorg 1.4.2 server which ships with netbsd-5 works
fine on non-BWX alphas.

--
Manuel Bouyer <bouyer@...>
     NetBSD: 26 ans d'experience feront toujours la difference
--


--
To UNSUBSCRIBE, email to debian-alpha-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...