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 <ni...@redhat.com> Date: Mar 7, 2014 7:34 AM Subject: Re: OpenRISC port ready for inclusion To: Olof Kindgren <olof.kindg...@gmail.com>, "binut...@sourceware.org" <binut...@sourceware.org> Cc: "openr...@lists.opencores.org" <openr...@lists.opencores.org>, openrisc <openr...@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
Please email the following information to ass...@gnu.org, and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. ---------------------------------------------------------------------- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?]
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
