This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: remove the "tile" architecture from glibc
On 12/01/2017 11:11 PM, Joseph Myers wrote:
>> But why should it be only up to Mellanox whether support for Tile is
>> part of glibc or not. I find straight up removal a bit too strong,
>> especially since QEMU supports Tile as well. I think the first step
>> should just be to mark the Tile port of glibc as unmaintained but not
>> remove it altogether. That could be too frustrating for people using
>> it. I'm pretty sure that there are more than just Mellanox' customers
>> who are using Linux on Tile.
>
> In practice, we need people with architecture expertise to resolve
> questions that arise about an architecture and review
> architecture-specific patches, and to run the tests before every release
> during the release freeze period and fix issues found so the release is in
> good shape for that architecture.
Yes, I'm aware of that and we in Debian are trying to help in these cases
where ever we can. We have several porterboxes for powerpc*, sparc*, alpha,
hppa and more available for porters and we're happy to create accounts for
anyone from glibc upstream to test any changes. In fact, Adhemerval Zanella
is already one of these users.
> SH is unmaintained; no test results posted for 2.26.
I will be happy to provide these results. Adhemerval has also access to one of
my SH porterboxes. Also, SH is actually being redeveloped as an open
source architecture called J-Core (http://j-core.org/) and they're working
on releasing new, SH-compatible open source hardware over the next years.
I already have J2 board at home, compatible SH-2.
> TILEPro hasn't had results posted for a long time, and TILE-Gx didn't have results posted for
> 2.26. The maintained state of MicroBlaze (email to maintainer bounced the
> last time I tried, test results in very poor shape) and IA64
> (libm-test-ulps patch from September still not committed, no results
> posted for 2.26) is questionable. I'd consider all of ia64 microblaze sh
> tilegx tilepro as candidates for obsoletion in the absence of active
> maintainers. People are of course welcome to volunteer as maintainers,
> but they do need to keep up with maintainer responsibilities (testing for
> each release and fixing any major issues and regenerating ulps if
> necessary, reviewing patches, answering questions about
> architecture-specific issues).
There is also a guy within Debian currently working on ia64 who started
recently. Don't know what the current status is though.
>> Yes, that would be great. If it's a known bug and there is a known,
>> working fix, it would be great if it could be merged upstream and
>> Tile support be kept for a while for the people hacking on Debian
>> on Tile.
>
> Someone will need to convert Tile GCC to use LRA instead of reload if that
> GCC port is to avoid obsoletion when reload is obsoleted. (CC0 obsoletion
> may be sooner, but I think the only glibc port that would imply obsoleting
> is m68k; all other glibc ports have non-CC0 GCC ports, but several don't
> use LRA.)
If m68k support is dropped, I'm either jumping out of the window or I'm
becoming a shepheard or something. Linux/m68k is one of *the* most popular
retro-platforms we have in Linux and there are lots of people in- and outside
Debian working on it. The kernel is still actively maintained on m68k with
at least four active maintainers that I know.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913