public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-mips] Status of Gentoo/MIPS developers
  @ 2010-01-09  4:32 99%   ` Matt Turner
  0 siblings, 0 replies; 1+ results
From: Matt Turner @ 2010-01-09  4:32 UTC (permalink / raw
  To: gentoo-mips

2010/1/8 Alexander Færøy <ahf@0x90.dk>:
> 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 [0] 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
instance).

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.

Matt

[0] http://devmanual.gentoo.org/archs/mips/index.html



^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2010-01-07  1:40     [gentoo-mips] Status of Gentoo/MIPS developers Matt Turner
2010-01-09  0:55     ` Alexander Færøy
2010-01-09  4:32 99%   ` Matt Turner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox