public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: gentoo-mips@lists.gentoo.org
Subject: Re: [gentoo-mips] Reducing the number of the MIPS supported stages
Date: Tue, 06 May 2014 17:37:22 -0400	[thread overview]
Message-ID: <53695612.40808@gentoo.org> (raw)
In-Reply-To: <536920DD.3080608@gentoo.org>

On 05/06/2014 13:50, Markos Chandras wrote:
> On 05/06/2014 09:10 AM, Joshua Kinard wrote:
>> On 05/06/2014 03:07, Markos Chandras wrote:
>>> @kumba: You mentioned too many times that I wanted to "drop" support for
>>> mips3 and mips4. I never said that (I am sort-of tired keep repeating
>>> that). All I said (again) was to reduce the frequency or stop building
>>> them at all. Users can still get an existing mips3/mips4 stage3 and
>>> update themselves
>>
>> Maybe it's just my way of interpretation, but in your opening paragraph,
>> even though you said we wouldn't drop support, you did suggest not creating
>> new stages for mips1-mips4.
>>
>> Given a sufficiently long-enough time, that effectively drops support due to
>> bitrot.  Like I mentioned w/ the 2009-era userland on this Octane, I am not
>> going to even try to update that, simply due to the amount of time it would
>> take, even if I figure the IRQ prioritization bugs out.
>>
>> So, my apologies if I read it wrong, but that's just how I see it.
>>
>>
>>> (picking up a random thread)
>>>
>>> Ok thanks for the replies.
>>>
>>> Ok I think it's safe to proceed with the following:
>>> - Stop mips1 builds (we don't have mips2)
>>
>> I'll defer to Matt to chime in to my last message and correct me anymore, if
>> needed, but, I think we'll want to keep either a mips1 or a mips2, but not
>> both.  As well as decide whether it's a full stage3 or just a simple
>> stage1/stage2 tarball so people have a base from which to start a port to a
>> new MIPS machine if needed.  That can get updated once a year, especially if
>> it's a stage1 which shouldn't take long at all.
> 
> I see no value for mips1 or mips2 so feel free to pick these up. Even if
> someone is using them as bootstrap, then *any* mips1 stage3 would do.

WFM.


>>> - Reduce the frequency to once-a-year for mips3 and mips4. Updating
>>> these stages every year with catalyst will be a lot of fun ;)
>>
>> NAK, At least once every 6 months, and preferably shortly after the .1
>> release of a new major gcc rev, given gcc's absurd compile time now.  Gentoo
>> moves fast, and a lot can change in a year.
> 
> Forgive me but this almost sounds like an order :) This is not going to
> happen, sorry :) I don't want to become a build robot and spend all my
> Gentoo/MIPS time doing stages. With the introduction of new ISAs, the
> total number of stages will grow even more, and like i explained
> multiple times, this does not scale. There are other parts of the
> architecture that needs some love too and right now I have no time for both.

It's not an order, sorry.  Just a preference to avoid long compile times.
If you have a stage3 built against gcc-4.8.x, and 4.9.x becomes stable,
someone installing will have to compile 4.9, then rebuild everything to gain
the enhancements 4.9 will bring.  If a new stage3 is built after the .1
release of a new major rev (so that we avoid major bugs in the .0 release),
that should mitigate that problem.


> And you haven't really convinced me why mips4 is desired, when mips3 can
> run just fine on mips4 hardware. I think you need to be realist, and
> take into consideration, not just your personal needs, but also the time
> it actually takes to build and maintain all these stages. I explained
> that so many times already, I am not going to do that again.
> As Anthony said, mipsel3 is used by lemote, so keeping it alive is
> probably a good thing (though the newer hardware is mips64 capable)

Well, to me, mips3 != mipsel3.  Sorry about that.  When I say mips3/mips4
(lowercase), I usually refer to big-endian.  If I capitalize the ISA, i.e.,
MIPS-III or MIPS-IV, then I'm referring to the entire ISA, regardless of
endianness.

So, to re-clarify my original statement, for big-endian SGI systems, we
probably only need mips4 and I guess the mips4_r10 stages.  I don't know if
any of our users still have or run R4x00 mips3 big-endian equipment.  If so,
well, I can do that too, then.  It's just a higher electric bill :)

And it's not really my personal preference.  Based on my understanding of
what we currently support, that's what makes sense to me.  I know you work
on MIPS stuff for your day job, but it's a hobby for me, so I have to
prioritize things a bit differently.  That said, I've done catalyst runs
before, so I know how time-consuming they can be, especially if the build
breaks somewhere in the middle of a long compile.

I think what we need to do is instead of having just one person like you or
Matt do all of the stage building, separate out the ISAs/ABIs/etc to the
people that actually care most about it.  Anthony works with the mipsel3
Lemote hardware, so if he wants, he can take care of mipsel3 stages; I'll
handle the SGI stuff since I know a lot about those machines; and you can
cover whichever of the newer ISAs matter most to you.

Sound reasonable?  We can even work out a set timetable for stage building,
or just release individual stages on an as-needed basis.


>> Otherwise, just e-mail me your mips3/mips4/mips4_r10 spec files, any custom
>> tweaks/changes to catalyst, and any specific instructions you do
>> before/during/after a catalyst build and I'll put the O2 to work if needed.
>>
> 
> There is nothing special about my spec files and I do nothing special in
> catalyst so feel free to pick up the mips3 and mips4 stages. If you are
> having troubles with catalyst email the gentoo-catalyst@ ML. That might
> actually be a good way for you to become active again ;)

Back in the past, I had to tweak catalyst sometimes to get it to do stage
builds properly.  A lot of those bugs have probably been fixed by now, at
least for stage1-3.  The livecd stages and netboots, however, were much more
problematic.

If you can still send me at least one of your stage3 spec files, that'd be
appreciated.  It's been 5-6 years since I last messed with catalyst.  The
Octane was my build platform, but combined with the bitrot that prevented it
from booting, moving, a new job, etc, I never got around to setting up stage
building on the O2.  Now that I can boot Octane again, I can at least
recover my old spec files, though.  Might help if I ever attempt to tackle
the livecd or netboot builds again.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


  reply	other threads:[~2014-05-06 21:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 14:06 [gentoo-mips] Reducing the number of the MIPS supported stages Markos Chandras
2014-05-05 17:04 ` Panagiotis Christopoulos
2014-05-05 17:17   ` Markos Chandras
2014-05-05 17:13 ` Justin Cormack
2014-05-05 17:16   ` Markos Chandras
2014-05-05 17:22 ` Matt Turner
2014-05-05 17:29   ` Markos Chandras
2014-05-05 23:34     ` Matt Turner
2014-05-05 22:02   ` Joshua Kinard
2014-05-05 23:30     ` Matt Turner
2014-05-06  0:15       ` Joshua Kinard
2014-05-05 23:36     ` Matt Turner
2014-05-06  0:09       ` Joshua Kinard
2014-05-06  7:07         ` Markos Chandras
2014-05-06  8:10           ` Joshua Kinard
2014-05-06 17:50             ` Markos Chandras
2014-05-06 21:37               ` Joshua Kinard [this message]
2014-05-07  7:06                 ` Markos Chandras
2014-05-07  7:22                   ` Joshua Kinard
2014-05-06 11:32           ` Anthony G. Basile
2014-05-06 17:40             ` Markos Chandras
2014-05-05 19:19 ` [gentoo-mips] " Anthony G. Basile
2014-05-05 19:33   ` Markos Chandras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53695612.40808@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox