<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head>
<body>
<body><p dir="ltr">Hi</p><p dir="ltr">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.</p><p dir="ltr">I think we can assume the tools will land at the FSF.</p><p dir="ltr">--Joel</p><div class="quote">---------- Forwarded message ----------<br>From: Nicholas Clifton <nickc@redhat.com><br>Date: Mar 7, 2014 7:34 AM<br>Subject: Re: OpenRISC port ready for inclusion<br>To: Olof Kindgren <olof.kindgren@gmail.com>, "binutils@sourceware.org" <binutils@sourceware.org><br>Cc: "openrisc@lists.opencores.org" <openrisc@lists.opencores.org>, openrisc <openrisc@openrisc.net><br><br type="attribution"></div></body>
<font size="2"><div class="PlainText">Hi Olaf,<br>
<br>
> What we have is a repo tracking upstream,a diff against<br>
> binutils-2.24.1 and all contributors to the OpenRISC-specific parts<br>
> are ready to sign over their respective parts to FSF... so how do we<br>
> proceed?<br>
<br>
Thanks very much for considering contributing this work. The first step <br>
is to make sure that all of the copyright holders for the work have FSF <br>
copyright assignments in place. (I am attaching the form necessary to <br>
apply for this assignment in case you need it).<br>
<br>
Next, send the patches to the binutils list for review. It helps if you <br>
can break the patches down by sub-directory, ie bfd, opcodes, gas, ld <br>
etc. It also helps if the code has been written following the GNU <br>
Coding Standards:<br>
<br>
<a href="http://www.gnu.org/prep/standards/">http://www.gnu.org/prep/standards/</a><br>
<br>
The patches should made against the current development sources and <br>
should compile without any problems on both 32-bit and 64-bit hosts. <br>
There is no need to submit patches against generate files (eg configure, <br>
bfd-in2.h, etc). It is helpful however if you can include ChangeLog <br>
entries describing the patches, although these are best presented as <br>
plain text rather than context diffs.<br>
<br>
It is also helpful if you can include some target specific testcases for <br>
both the assembler and the linker, to verify that the port is working. <br>
You should also build a toolchain configured with <br>
"--enable-targets=all", just to make sure that your changes do not <br>
affect any other targets.<br>
<br>
You should also consider who will be maintaining the port. If the port <br>
is not going to have a maintainer who will help to look after it then it <br>
is unlikely to be accepted in the first place. (Unmaintained code tends <br>
to bit-rot and cause complications for other targets).<br>
<br>
Cheers<br>
Nick<br>
<br>
</div></font>
</body>
</html>