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