On Sat, Dec 2, 2017 at 4:16 PM, John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 12/02/2017 02:14 AM, Chris Metcalf wrote:
>
>> I'd be very happy if someone from Debian (for example) wants to sign
>> up as maintainer. Otherwise I will follow the sense of the community
>> in terms of whether deletion or just marking it as unmaintained feels
>> like the better way to go.
>
> I will ask around the Debian community what the current state of the
> Tilegx bootstrap is. Again, thanks for your help!
Do you have any updates on this? A related question has come up
for the kernel, as are in the process of removing a number of architectures,
https://lwn.net/SubscriberLink/748074/119aaf0d62b3e6c1/ or
see https://lwn.net/Articles/748074/ for a nice summary.
It looks like we might remove blackfin and/or mn10300 at the same
time as the others, which would leave tile as the one architecture
whose future still remains unclear.
This is what I understand from previous discussions:
- Mellanox has stopped all work on the architecture, both kernel
and glibc
- Cisco are using a heavily patched older kernel and mainline
toolchains, they would not care about the kernel dropping
the port (based on Henrik's mail in this thread)
- Mikrotik are probably using a similar kernel (I found a large
3.3.5 based patch for tile in their latest download sources),
so I'm guessing they wouldn't care either.
- There was a minor effort back in 2014 to try to get OpenWRT
to run on mikrotik tile-gx based devices, but that doesn't seem
to have gone anywhere
(see https://forum.mikrotik.com/viewtopic.php?t=85713,
https://forum.openwrt.org/viewtopic.php?id=50897)
- Helmut Grohne has done the work to add tile-gx to debian
rebootstrap, and send several patches, as seen in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
However, I could find no information on this actually
being turned into a full port, or anyone still actively involved
in it. The Debian rebootstrap page at
https://wiki.debian.org/HelmutGrohne/rebootstrap
mentions lots of other architectures, but not this one.
Does anyone have any additional information here? If there
is still active work on OpenWRT or Debian for TileGX, I don't
want to hurt that, but if the port is indeed as dead as it seems
based on my findings above, then it would be convenient to
remove it from the kernel together with the other architectures
rather than waiting a few more releases.
Arnd
On Wed, 7 Mar 2018, Arnd Bergmann wrote:
> Do you have any updates on this? A related question has come up
> for the kernel, as are in the process of removing a number of architectures,
> https://lwn.net/SubscriberLink/748074/119aaf0d62b3e6c1/ or
> see https://lwn.net/Articles/748074/ for a nice summary.
No-one has posted glibc test results for 2.27 or 2.26, despite the prior
claims of interest in keeping the glibc port. If the kernel port is
removed, my assumption is that we should remove the glibc port at that
point (not keep it around for possible use with older kernels).
--
Joseph S. Myers
[email protected]
On 03/07/2018 05:00 PM, Joseph Myers wrote:
> No-one has posted glibc test results for 2.27 or 2.26, despite the prior
> claims of interest in keeping the glibc port.
To be honest, I find the rapid release model for glibc a bit annoying
as a downstream. Upstream projects which adopt this model and then require
constant attention from porters cause lots of stress for the less common
architectures. There are other upstream projects that want attention as
well and at some point it just will get extremely frustrating.
Is such a rapid release model really needed for something like a C library?
As for the testsuites: Adhemerval has gotten access from Debian to a
number of porterboxes for the various uncommon architectures, including
alpha, hppa, powerpcspe, sh4 and sparc64 and we're happy to give out
accounts to anyone interested.
And since Debian regularly updates glibc as well, you can get most testsuite
runs also by just checking the build logs (click on the green or red texts):
> https://buildd.debian.org/status/package.php?p=glibc&suite=sid
Note: Testsuites for sh4 and m68k are currently disabled.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Wed, Mar 07, 2018 at 04:39:47PM +0100, Arnd Bergmann wrote:
> - Helmut Grohne has done the work to add tile-gx to debian
> rebootstrap, and send several patches, as seen in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
> However, I could find no information on this actually
> being turned into a full port, or anyone still actively involved
> in it. The Debian rebootstrap page at
> https://wiki.debian.org/HelmutGrohne/rebootstrap
> mentions lots of other architectures, but not this one.
I happened help tilegx, because Adrian found someone with hw and tilegx
appeared to be very well maintained upstream. Very little needed to be
done to make it work in Debian. The patches I sent were pretty generic
and addressed issues that most ports face. What is there allows
constructing most of an essential package set and (unlike a number of
other architectures) bootstrapping tilegx works fairly well. Debian has
a number of source-only ports and tilegx is now one of them.
That said, nobody has taken up the work to proceed a native bootstrap.
Like with nios2, progress is stalled, because the tooling for fully
automating the native phase is missing.
In any case, I won't be able to fix binutils/gcc/glibc/linux issues with
tilegx. So unless someone steps up to do that work, I won't object to
dropping it. It would be sad to see tilegx go, but it certainly isn't my
core interest either.
I'd appreciate a note if it gets dropped from any of these, because I'd
clean up outstanding bug reports then.
The reverse is also true: If you want to see an new architecture in
Debian, I also appreciate an early conversation to avoid duplicating
work.
Hope this helps
Helmut
On Wed, Mar 7, 2018 at 7:14 PM, Helmut Grohne <[email protected]> wrote:
> On Wed, Mar 07, 2018 at 04:39:47PM +0100, Arnd Bergmann wrote:
>> - Helmut Grohne has done the work to add tile-gx to debian
>> rebootstrap, and send several patches, as seen in
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
>> However, I could find no information on this actually
>> being turned into a full port, or anyone still actively involved
>> in it. The Debian rebootstrap page at
>> https://wiki.debian.org/HelmutGrohne/rebootstrap
>> mentions lots of other architectures, but not this one.
>
> I happened help tilegx, because Adrian found someone with hw and tilegx
> appeared to be very well maintained upstream. Very little needed to be
> done to make it work in Debian. The patches I sent were pretty generic
> and addressed issues that most ports face. What is there allows
> constructing most of an essential package set and (unlike a number of
> other architectures) bootstrapping tilegx works fairly well. Debian has
> a number of source-only ports and tilegx is now one of them.
>
> That said, nobody has taken up the work to proceed a native bootstrap.
> Like with nios2, progress is stalled, because the tooling for fully
> automating the native phase is missing.
>
> In any case, I won't be able to fix binutils/gcc/glibc/linux issues with
> tilegx. So unless someone steps up to do that work, I won't object to
> dropping it. It would be sad to see tilegx go, but it certainly isn't my
> core interest either.
>
> I'd appreciate a note if it gets dropped from any of these, because I'd
> clean up outstanding bug reports then.
I originally helped get tile, blackfin, metag, unicore32 and score into
the kernel, and it's always sad to see them go away after all the work
that was put into making them work. Out of the above, tile was
probably the best supported, and the most ambitious architecture
design, but in the end it seems it is just as dead as the others, so
I'll now add a patch to remove it along with the others in linux-4.17.
Thanks for providing some more background, that definitely helped
make the decision easier. The other point that I found is that the
Mikrotik CCR hardware is from 2012 when tilegx was still fairly
new, and if nobody has done a full port in the first six years of the
product life-cycle, it seems very unlikely to change before the CCR
itself becomes obsolete.
> The reverse is also true: If you want to see an new architecture in
> Debian, I also appreciate an early conversation to avoid duplicating
> work.
I checked the list of architectures in rebootstrap, and besides tile,
no other is currently in danger of being removed. There are however
a couple things I'd note:
- The openrisc debian port was "declared dead" a few years ago
due to copyright issues. These are apparently getting addressed
now at least for gcc (I know nothing about the glibc problems or
any work on solutions). This might come back soon, but at
the same time my impression is that the OpenRISC community
is shrinking due to RISC-V replacing it in many new projects.
- The latest architecture to get merged into linux (also 4.17) is
nds32. I'm meeting the maintainer (Greentime Hu) next week
and will ask him about whether they are interested in a Debian
port. nds32 is widely deployed in certain markets today, but the
latest Andestech CPUs are RISC-V based, so it's also unclear
whether this one has a long-term future.
- sh3/sh4 looked like they would get revived a few years ago
for the j-core project. The 2015 roadmap on
http://j-core.org/roadmap.html had ambitious plans for
an sh3 compatible core in 2017 and an sh4 compatible one
in 2018. However, not much has happened at all since 2016,
and now the website is down as well. You might want to
contact the j-core developers for clarification.
I suspect this has also become a victim of the RISC-V
success.
- arm64be has some active users, and is supported in the toolchain
and by most arm64 hardware (notably not those using UEFI to
boot IIRC).
- riscv32 is not yet supported by Linux or glibc, but that seems
very likely to come in the future, maybe one or two years from
now.
Arnd
On 03/08/2018 04:55 PM, Arnd Bergmann wrote:
> I originally helped get tile, blackfin, metag, unicore32 and score into
> the kernel, and it's always sad to see them go away after all the work
> that was put into making them work. Out of the above, tile was
> probably the best supported, and the most ambitious architecture
> design, but in the end it seems it is just as dead as the others, so
> I'll now add a patch to remove it along with the others in linux-4.17.
Out of curiosity: Is there any reason why the removal of tilegx is now
being rushed? Did any of the policies regarding architectures in the
kernel change? I had the impression that architectures could previously
stay unmaintained for a while before being removed.
> - sh3/sh4 looked like they would get revived a few years ago
> for the j-core project. The 2015 roadmap on
> http://j-core.org/roadmap.html had ambitious plans for
> an sh3 compatible core in 2017 and an sh4 compatible one
> in 2018. However, not much has happened at all since 2016,
> and now the website is down as well. You might want to
> contact the j-core developers for clarification.
> I suspect this has also become a victim of the RISC-V
> success.
Well, that's quite a bummer. I don't know what Rich Felker's and
Rob Landley's plans now are. Rich told that he would be doing paid
SH work again in the upcoming weeks. I even sent him and Rob SH4
hardware to support their efforts.
I have personally invested a lot of work into the SH port over the
past three years in Debian and I was involved fixing many bugs
and as a result, the port is quite usable. It would be really
disappointing to see it being removed all of a sudden :(.
I will get in touch with Rich and Rob to figure out what's going
on.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, Mar 8, 2018 at 5:06 PM, John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 03/08/2018 04:55 PM, Arnd Bergmann wrote:
>>
>> I originally helped get tile, blackfin, metag, unicore32 and score into
>> the kernel, and it's always sad to see them go away after all the work
>> that was put into making them work. Out of the above, tile was
>> probably the best supported, and the most ambitious architecture
>> design, but in the end it seems it is just as dead as the others, so
>> I'll now add a patch to remove it along with the others in linux-4.17.
>
>
> Out of curiosity: Is there any reason why the removal of tilegx is now
> being rushed? Did any of the policies regarding architectures in the
> kernel change? I had the impression that architectures could previously
> stay unmaintained for a while before being removed.
No, nothing changed, we're normally just really bad at identifying
stuff that can go away exactly because that is the kind of thing
that nobody cares about any more.
I picked up the task to remove some of the stale architectures after
building a set of cross-compilers and noticing that some architectures
(score, unicore32, metag) are not supported by mainline gcc.
This has led me to a few more that I'm now removing after
making sure that nobody still wants them: m32r, frv, mn10300,
blackfin, cris and tile. I was planning to give some of these a
few more releases before removing them, but after talking with
the people that worked on them, the answer was always that
it's sad to let them go, but there is really no reason to keep
them.
I definitely hope that I did my research well, but if you can think
of any remaining users of upstream kernels that I missed, then
please let me know and I'll hold off on the removal for that
architecture.
The reason I want to do them all at once is that it takes a bit
of work to find all the architecture specific code in the kernel
outside of the arch/ directory, and removing nine architectures
at once makes that process much more efficient overall.
>> - sh3/sh4 looked like they would get revived a few years ago
>> for the j-core project. The 2015 roadmap on
>> http://j-core.org/roadmap.html had ambitious plans for
>> an sh3 compatible core in 2017 and an sh4 compatible one
>> in 2018. However, not much has happened at all since 2016,
>> and now the website is down as well. You might want to
>> contact the j-core developers for clarification.
>> I suspect this has also become a victim of the RISC-V
>> success.
>
>
> Well, that's quite a bummer. I don't know what Rich Felker's and
> Rob Landley's plans now are. Rich told that he would be doing paid
> SH work again in the upcoming weeks. I even sent him and Rob SH4
> hardware to support their efforts.
>
> I have personally invested a lot of work into the SH port over the
> past three years in Debian and I was involved fixing many bugs
> and as a result, the port is quite usable. It would be really
> disappointing to see it being removed all of a sudden :(.
>
> I will get in touch with Rich and Rob to figure out what's going
> on.
Ok, thanks! I'd definitely like to know what's going on as well.
Arnd
On Thu, 08 Mar 2018 07:55:33 PST (-0800), Arnd Bergmann wrote:
> - riscv32 is not yet supported by Linux or glibc, but that seems
> very likely to come in the future, maybe one or two years from
> now.
I'm hoping it'll be a lot less than a year away :).
On Thu, Mar 8, 2018 at 6:14 PM, Palmer Dabbelt <[email protected]> wrote:
> On Thu, 08 Mar 2018 07:55:33 PST (-0800), Arnd Bergmann wrote:
>>
>> - riscv32 is not yet supported by Linux or glibc, but that seems
>> very likely to come in the future, maybe one or two years from
>> now.
>
>
> I'm hoping it'll be a lot less than a year away :).
Ah, very good. For some reason I was under the impression that all
the early hardware with Linux support was 64-bit only, and the
32-bit Linux port therefore a low priority, but even better if that's
coming soon.
Arnd
On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote:
> I have personally invested a lot of work into the SH port over the
> past three years in Debian and I was involved fixing many bugs
> and as a result, the port is quite usable. It would be really
> disappointing to see it being removed all of a sudden :(.
Note that SH glibc test results need some work - there are a large number
of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.
Probably most could be addressed with the NaN fixes I outlined at
<https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that
does of course need someone to do the work to implement that in GCC and
glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't
seem very specific on this, but the existing setting was definitely
determined by testing on hardware. SH experts with access to a range of
different hardware may be needed to advise on what different hardware does
or is supposed to do in this regard.)
The glibc port whose test results cause me the most concern that it's
effectively unmaintained and should be considered for obsoletion is
MicroBlaze - the results
<https://sourceware.org/glibc/wiki/Release/2.27#MicroBlaze> are clearly a
big mess (not something where one fix would probably resolve most failures
as on SH) and there's no sign of activity to sort them out (nor has there
been such activity for a long time).
--
Joseph S. Myers
[email protected]
On 03/09/2018 05:31 PM, Joseph Myers wrote:
> Note that SH glibc test results need some work - there are a large number
> of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.
> Probably most could be addressed with the NaN fixes I outlined at
> <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that
> does of course need someone to do the work to implement that in GCC and
> glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't
> seem very specific on this, but the existing setting was definitely
> determined by testing on hardware. SH experts with access to a range of
> different hardware may be needed to advise on what different hardware does
> or is supposed to do in this regard.)
Ok, thanks for the explanation.
On a sidenote: Is there documentation somewhere which explains how to properly
run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
for m68k.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote:
> On 03/09/2018 05:31 PM, Joseph Myers wrote:
> > Note that SH glibc test results need some work - there are a large number
> > of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.
> > Probably most could be addressed with the NaN fixes I outlined at
> > <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that
> > does of course need someone to do the work to implement that in GCC and
> > glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't
> > seem very specific on this, but the existing setting was definitely
> > determined by testing on hardware. SH experts with access to a range of
> > different hardware may be needed to advise on what different hardware does
> > or is supposed to do in this regard.)
>
> Ok, thanks for the explanation.
>
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.
"make check", or "make -k check" if you're concerned about some tests
failing to build (e.g. the compiler running out of memory on a few large
tests) - the testsuite should continue after execution failures, but not
after compilation failures. (Having previously configured with
--prefix=/usr for the build. And if the compiler used doesn't have
libgcc_s and libstdc++ shared libraries in directories ld.so searches by
default, you should copy those libraries into the glibc build directory
before running tests.) On a system that can handle it you'd use an
appropriate -jN option for parallelism, but probably not on m68k.
For cross testing over SSH (when glibc is running on a system that is very
slow running the compiler or has too little memory to do so) you need a
shared filesystem at the same path on both the system where glibc is built
and the system where tests will execute (probably NFS-exported from the
build system, and it may be necessary to mount it on the test system with
acdirmax=0,acdirmin=0 to limit any caching). Then you can pass
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh <host>" to make
check.
In both cases, for very slow test systems you may wish to export
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).
--
Joseph S. Myers
[email protected]