Re: [openrisc] Re: ports to 2.96 and 3.1 versions

["Damjan Lampret" <lampret at opencores dot org>]

FYI just some info about our port:

1) Port for OpenRISC doesn't change any parts of the GCC except configure
files and it adds port depending files under gcc/gcc/config/or32
2) Until recently we used our "target part" with the 2.95.2; it didn't
change for the last six month, it is very stable and it compiles uClinux and
we run uClinux on HW. It is true that we just recently switched to 3.1, but
3.1 compiles our test suite w/o problems and the suite runs correctly on
simulator. So I'm quite sure 3.1 will also handle uClinux well - we'll
compile it and run it on HW in a few days.

For us (the openrisc/opencores team) it is very important to get our
software tools into official distributions. In the open source/free spirit
of our both projects, I think our port should be part of the official
distribution. Also we might get more software people to help us in our
little project. Afterall we have put quite some work into it (not just gcc,
but also in other tools and into rest of the non-SW project). So we hope you
will not let us wait until October so that our port gets into a release.
Of course we will do what is necessary and required (copyright assignments,
fix coding style if there will be complaints, etc etc).

regards,
Damjan

----- Original Message -----
From: "mike stump" <mrs@windriver.com>
To: <gcc@gcc.gnu.org>; <robertlipe@usa.net>
Cc: <markom@opencores.org>; <openrisc@opencores.org>
Sent: Thursday, January 24, 2002 8:30 PM
Subject: [openrisc] Re: ports to 2.96 and 3.1 versions


> > Date: Thu, 24 Jan 2002 13:11:00 -0600
> > From: Robert Lipe <robertlipe@usa.net>
> > To: gcc@gcc.gnu.org
>
> > We really should revisit this process since we have had a couple of
> > ports recently that are in this same flight pattern.
>
> You'd need to communicate what you thought was broken with status quo
> and what changes you wanted to see to it and why it would be better.
> Absent at least a suggestion of how it could be made better...  I
> don't know what there is to talk about.
>
> > If we could get the bulky stuff of a new port reviewed, approved, and
> > installed early, wouldn't that be a Good Thing?
>
> Agreed.
>
> > If we could get all the configury gunk and the totally new files in,
> > there would be no risk to existing targets and could therefore
> > reasonably go in at this point in the cycle.
>
> Agreed (if the maintainer that is reviewing the patches feels this is
> true).  Bear in mind, sometimes ports are invasive and do contain bugs
> that do affect other platforms.
>
> > Would that work?
>
> I don't see much disagreement between what you've said, and what
> little I know of the policy.
>
>
> I guess the main one is this, can a new port be accepted in stage 3,
> if it is is clean enough in how it affects other ports?  Off hand, I
> don't see much harm in it, other than incomplete work being in the
> tree.  If we mandate it only goes in as last as stage2, stage3 is
> there to put the finishing touches on the port.  Or, we could accept
> it as late as stage3 because it doesn't affect other ports.
>
> Personally, I'm happy to let the release manager make the call how
> they may, and live with the decision and after we hear more about why
> the process is broken, then decide to change it.  If a release manager
> wanted to document his ideas about new ports and phase 2 or 3 on the
> web site, I think that would be reasonable and help set expectations
> of contributors.  If the steering committee wanted to set policy (and
> document it on the web page), that would seem to be reasonable.  I
> don't see that this _needs_ to be done however.
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>