2010/1/8 Alexander Færøy <ahf@...>:
> On Wed, Jan 06, 2010 at 08:40:53PM -0500, Matt Turner wrote:
>> I'd really like to put Gentoo on my O2s, and can help out myself, but
>> a couple active developers would be nice.
> I'd personally just try to install Gentoo on my O2 and see if something
> breaks. Usually these machines are fairly well-supported upstream-wise,
> so hopefully you wont see much breakage.
I don't see any point in using the o32 ABI, so I tried the 2006.1 n32
stage (the _latest_ is 2006.1...) and after a couple failed attempts,
I've decided it's too far gone to be of any use.
> Gentoo/MIPS has been pretty much inactive for the past years, mainly due
> to lack of time amongst the development team, but also because it's
> difficult to find powerful enough hardware that allows you to get your
> job done tonight and not in fourteen days.
Yes, compiling stuff like glibc is quite time consuming on an O2.
To me, the problem seems to actually be a collection of problems.
First, there is as you said a lack of usably fast MIPS hardware.
Octeon stuff is unobtainable, as is most new MIPS hardware. And the
later generation SGI systems are entirely unsupported in Linux.
(OpenBSD for a comparison seems to have increasingly good support of
IP35+). It looks to me that current mips kernel development is limited
to high-end, unobtainable mips systems, and Lemote. That is to say, no
SGI development. Quad 600 MHz Origin 300s with 4GB RAM are _cheap_.
That'd be the ticket to affordable and fast mips systems if the kernel
support was there.
On top if that, the Gentoo devmanual states  that in order to mark
a package as ~mips, "[t]he package should work on both big and little
endian systems, on both pure 32 bit and pure 64 bit systems and on
systems with differing kernel and userland ABIs." That means testing
on (big endian/little endian) x (32bit/64bit/mixed kernel/user) x
(o32/n32/n64) == 18 potential combinations. (I guess actually less.
I'm not sure how you could have an o32-pure-64-bit system for
God. Let's dump o32 already. That cuts the number to 12. At this
point, it's still ridiculous to ask a single developer to test this
many configurations. Split ~mips into ~mips-be and ~mips-le or
something. This would certainly make it more manageable. Whatever the
case, we've got to limit the range of possible configurations.
> Of course you could just start buggering them on IRC or on this
> mailing-list with various patches and such :)
Well. There are two developers on IRC. I talk to them occasionally,
but I don't think constant prodding is the way to productivity.