Re: [PATCH] MIPS: lib: prefetch ahead in csum_partial()

[Maciej W. Rozycki]

Hi Geert,

> >  I'd estimate it as one day worth of engineering effort plus maybe another
> > one for machines to work through verification, for the binutils side and
> > the associated changes needed for GCC, i.e. a `-march=' option update plus
> > maybe enabling a couple of existing machine description patterns for the
> > Tx49 too.  Would you be able to run GCC verification with your system?
> 
> The rbtx4927 is about the slowest system I still do regular testing on.

 Speed is of no essence, I've recently run regression-testing with a R3k 
DECstation, a VAXstation (with NetBSD), and previously, as a day job, with 
a crippled ARM board well below the capabilities of the former systems.  
Depending on the components chosen and the amount of breakage triggered by 
the tests themselves (timeouts!) it could take from several hours to a few 
days.

> It uses a Debian 8 nfsroot (over 10 Mbps Ethernet), which is the latest
> Debian release still supporting the instruction subset suppported
> by TX49XX.

 I run most of my target systems NFS-rooted as well (over 100Mbps FDDI for 
a change).  Little is required from the target environment: an SSH server 
and a POSIX shell, and then either an NFS client for direct build system 
access or rsync for remote sysroot maintenance (in which case `rm' command 
is needed too to discard test cases copied over, once executed).

> So as long as no native compilation of large packages is required,
> it can be done.  I can also give you remote access?

 There is no native compilation at all, only remote execution over SSH, 
driven from the build system by DejaGNU.

 As for remote access, that would be an option, perhaps an easy one since 
I've done it before with someone else, as long as you can offer temporary 
storage for the sysroot to operate the target system with (~225MiB for 
o32, ~285MiB for n64, indicative) and some network bandwidth.

  Maciej