Fwd: OpenRISC port ready for inclusion

[Joel Sherrill]

Hi

One issue I forgot about a new architecture port is that since you will be tweaking the GNU tools to add a new target, you must have an assignment on file with the FSF. Please start this now.

I think we can assume the tools will land at the FSF.

--Joel

---------- Forwarded message ----------
From: Nicholas Clifton <nickc at redhat.com>
Date: Mar 7, 2014 7:34 AM
Subject: Re: OpenRISC port ready for inclusion
To: Olof Kindgren <olof.kindgren at gmail.com>, "binutils at sourceware.org" <binutils at sourceware.org>
Cc: "openrisc at lists.opencores.org" <openrisc at lists.opencores.org>, openrisc <openrisc at openrisc.net>

Hi Olaf,

> What we have is a repo tracking upstream,a diff against
> binutils-2.24.1 and all contributors to the OpenRISC-specific parts
> are ready to sign over their respective parts to FSF... so how do we
> proceed?

Thanks very much for considering contributing this work.  The first step
is to make sure that all of the copyright holders for the work have FSF
copyright assignments in place.  (I am attaching the form necessary to
apply for this assignment in case you need it).

Next, send the patches to the binutils list for review.  It helps if you
can break the patches down by sub-directory, ie bfd, opcodes, gas, ld
etc.  It also helps if the code has been written following the GNU
Coding Standards:

   http://www.gnu.org/prep/standards/

The patches should made against the current development sources and
should compile without any problems on both 32-bit and 64-bit hosts.
There is no need to submit patches against generate files (eg configure,
bfd-in2.h, etc).  It is helpful however if you can include ChangeLog
entries describing the patches, although these are best presented as
plain text rather than context diffs.

It is also helpful if you can include some target specific testcases for
both the assembler and the linker, to verify that the port is working.
You should also build a toolchain configured with
"--enable-targets=all", just to make sure that your changes do not
affect any other targets.

You should also consider who will be maintaining the port.  If the port
is not going to have a maintainer who will help to look after it then it
is unlikely to be accepted in the first place.  (Unmaintained code tends
to bit-rot and cause complications for other targets).

Cheers
   Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140307/3d634a51/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: request-assign.future
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140307/3d634a51/attachment.ksh>