Deprecating and removing old targets

Deprecating and removing old targets

[Tristan Gingold]

Hello,

after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
It is hard to know whether or not they are used, so if you are using an old target please speak up.

By old target, I mean any non-ELF target for which OS wasn't update in the last 10 years.
Without a complete search, I think about:

* all a.out targets
* all NetWare targets (nlm)
* all ecoff targets (alpha and mips)
* very old cpus: m88k, ns32k, i960, appolo, w65, we32k, pc532
* very old os: sunos-4, irix, sco, newsos, OSF, risc-ix
* very old formats: ieee-695, xsym, ppcboot, pef

I may forget some of them...

Targets I think we should keep:
* vax
* z80
* pdp11
* m68k, m68xx
* hppa
* alpha (elf, vms)
* dlx

Tristan.

Re: Deprecating and removing old targets

[Oleg Endo]

On Mon, 2016-09-12 at 09:37 +0200, Tristan Gingold wrote:
> 
> * all a.out targets
> * all NetWare targets (nlm)
> * all ecoff targets (alpha and mips)
> * very old cpus: m88k, ns32k, i960, appolo, w65, we32k, pc532
> * very old os: sunos-4, irix, sco, newsos, OSF, risc-ix
> * very old formats: ieee-695, xsym, ppcboot, pef
> 
> I may forget some of them...
> 
> Targets I think we should keep:
> * vax
> * z80
> * pdp11
> * m68k, m68xx
> * hppa
> * alpha (elf, vms)
> * dlx

+1 for keeping 68K and Z80 in :)

Cheers,
Oleg

Re: Deprecating and removing old targets

[Paul.Koning]

> On Sep 12, 2016, at 3:37 AM, Tristan Gingold <gingold@adacore.com> wrote:
> 
> Hello,
> 
> after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
> It is hard to know whether or not they are used, so if you are using an old target please speak up.
> 
> By old target, I mean any non-ELF target for which OS wasn't update in the last 10 years.
> Without a complete search, I think about:
> 
> * all a.out targets
> ...
> Targets I think we should keep:
> * vax
> * z80
> * pdp11

Sounds reasonable.  I'm partial to pdp11.  But isn't pdp11 an a.out target?  

	paul

Re: Deprecating and removing old targets

[Tristan Gingold]

> On 12 Sep 2016, at 17:37, Paul.Koning@dell.com wrote:
> 
> 
>> On Sep 12, 2016, at 3:37 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> 
>> Hello,
>> 
>> after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
>> It is hard to know whether or not they are used, so if you are using an old target please speak up.
>> 
>> By old target, I mean any non-ELF target for which OS wasn't update in the last 10 years.
>> Without a complete search, I think about:
>> 
>> * all a.out targets
>> ...
>> Targets I think we should keep:
>> * vax
>> * z80
>> * pdp11
> 
> Sounds reasonable.  I'm partial to pdp11.  But isn't pdp11 an a.out target?  

Ah, ah!  You're right.

So I suppose you'd like to keep pdp11 and a.out ?

Tristan.

Re: Deprecating and removing old targets

[Joel Sherrill]

On 9/12/2016 6:58 AM, Oleg Endo wrote:
> On Mon, 2016-09-12 at 09:37 +0200, Tristan Gingold wrote:
>>
>> * all a.out targets
>> * all NetWare targets (nlm)
>> * all ecoff targets (alpha and mips)
>> * very old cpus: m88k, ns32k, i960, appolo, w65, we32k, pc532
>> * very old os: sunos-4, irix, sco, newsos, OSF, risc-ix
>> * very old formats: ieee-695, xsym, ppcboot, pef
>>
>> I may forget some of them...
>>
>> Targets I think we should keep:
>> * vax
>> * z80
>> * pdp11
>> * m68k, m68xx

I don't think these two should have been lumped together.
The m68k covers m68k and Coldfire. I think with Freescale
now being part of NXP, I am not sure if any Coldfire part
is recommended for new designs or not but they are out
there and projects will be using them for a long time.

 From an RTEMS perspective, we have users still hanging
on to m68040 VMEBus boards. As long as there is a NIC,
the boards are still useful and paid for in at least some
national labs. They have them and use them.

the m68xx's I recall were 8 bit parts although I think
some are 16.

>> * hppa
>> * alpha (elf, vms)
>> * dlx
>
> +1 for keeping 68K and Z80 in :)

I agree.

> Cheers,
> Oleg
>
--joel

Re: Deprecating and removing old targets

[Paul.Koning]

> On Sep 12, 2016, at 11:50 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> ...
>> Sounds reasonable.  I'm partial to pdp11.  But isn't pdp11 an a.out target?  
> 
> Ah, ah!  You're right.
> 
> So I suppose you'd like to keep pdp11 and a.out ?

Yes, indeed.  If it needs a maintainer to volunteer in order for it to be kept, I will do that if there isn't anyone else; after all I did for GCC...

	paul

Re: Deprecating and removing old targets

[Pedro Alves]

On 09/12/2016 08:37 AM, Tristan Gingold wrote:
> Hello,
> 
> after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
> It is hard to know whether or not they are used, so if you are using an old target please speak up.
> 
> By old target, I mean any non-ELF target for which OS wasn't update in the last 10 years.
> Without a complete search, I think about:
> 
> * all a.out targets

I posted a gdb patch to drop all a.out support from GDB a
while ago.  I had forgotten about it meanwhile.  I'll dig it
up and see about pushing it to master soon.

Thanks,
Pedro Alves

Re: Deprecating and removing old targets

[Matthias Klose]

On 12.09.2016 09:37, Tristan Gingold wrote:
> Targets I think we should keep:
> * vax
> * z80
> * pdp11
> * m68k, m68xx
> * hppa
> * alpha (elf, vms)
> * dlx

while not release architectures, Debian still builds for alpha, hppa and m68k.

Matthias

Re: Deprecating and removing old targets

[Paul Koning]

> On Sep 13, 2016, at 6:07 AM, Pedro Alves <palves@redhat.com> wrote:
> 
> On 09/12/2016 08:37 AM, Tristan Gingold wrote:
>> Hello,
>> 
>> after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
>> It is hard to know whether or not they are used, so if you are using an old target please speak up.
>> 
>> By old target, I mean any non-ELF target for which OS wasn't update in the last 10 years.
>> Without a complete search, I think about:
>> 
>> * all a.out targets
> 
> I posted a gdb patch to drop all a.out support from GDB a
> while ago.  I had forgotten about it meanwhile.  I'll dig it
> up and see about pushing it to master soon.

Binutils and gdb have similar target sets, but they aren't identical.  For example, pdp11 isn't a gdb target but is a binutils and gcc target.

	paul

Re: Deprecating and removing old targets

[Pedro Alves]

On 09/13/2016 02:04 PM, Paul Koning wrote:
> 
>> On Sep 13, 2016, at 6:07 AM, Pedro Alves <palves@redhat.com> wrote:
>>
>> On 09/12/2016 08:37 AM, Tristan Gingold wrote:

>>> * all a.out targets
>>
>> I posted a gdb patch to drop all a.out support from GDB a
>> while ago.  I had forgotten about it meanwhile.  I'll dig it
>> up and see about pushing it to master soon.
> 
> Binutils and gdb have similar target sets, but they aren't identical.  For example, pdp11 isn't a gdb target but is a binutils and gcc target.

Yup.

The thing is that if we remove support for some port from binutils,
then we need to remove it from gdb too, because gdb uses bfd, etc.,
as you know, otherwise, it's possible that an --enable-targets=all
build breaks.

Or seen from the other angle, if we don't want to remove it
from gdb, then we need to keep it in bfd too, etc.  (Not that
I expect that)

So for a.out in particular, I was implying that while gdb still includes
some support for a.out, it's already scheduled for deletion, so that
shouldn't be a blocker.  I should have been more explicit,
sorry about that.

To be clear, I'm all for removal of old unused ports.

Thanks,
Pedro Alves

Re: Deprecating and removing old targets

[Jeff Law]

On 09/13/2016 04:38 AM, Matthias Klose wrote:
> On 12.09.2016 09:37, Tristan Gingold wrote:
>> Targets I think we should keep:
>> * vax
>> * z80
>> * pdp11
>> * m68k, m68xx
>> * hppa
>> * alpha (elf, vms)
>> * dlx
>
> while not release architectures, Debian still builds for alpha, hppa and m68k.
They were in the keep list.

We might consider dropping hppa-som, which is an HPUX 32 bit only object 
format.  We'd keep ELF for the linux port.

Similarly we could consider dropping some of the other object format 
support for m68k and keep ELF for the linux ports.

I've got no strong opinions on this stuff -- I only mention it because 
I've worked on them in the past.

jeff

Re: Deprecating and removing old targets

[Joel Sherrill]

On September 13, 2016 9:03:24 AM CDT, Jeff Law <law@redhat.com> wrote:
>On 09/13/2016 04:38 AM, Matthias Klose wrote:
>> On 12.09.2016 09:37, Tristan Gingold wrote:
>>> Targets I think we should keep:
>>> * vax
>>> * z80
>>> * pdp11
>>> * m68k, m68xx
>>> * hppa
>>> * alpha (elf, vms)
>>> * dlx
>>
>> while not release architectures, Debian still builds for alpha, hppa
>and m68k.
>They were in the keep list.
>
>We might consider dropping hppa-som, which is an HPUX 32 bit only
>object 
>format.  We'd keep ELF for the linux port.
>
>Similarly we could consider dropping some of the other object format 
>support for m68k and keep ELF for the linux ports.
>
>I've got no strong opinions on this stuff -- I only mention it because 
>I've worked on them in the past.

FWIW where at all possible RTEMS uses ELF and from a binutils perspective is the same as the CPU-elf target. At this point, I don't think we have any target not using ELF.

>jeff

--joel

Re: Deprecating and removing old targets

[Joseph Myers]

On Tue, 13 Sep 2016, Jeff Law wrote:

> We might consider dropping hppa-som, which is an HPUX 32 bit only object
> format.  We'd keep ELF for the linux port.

Which would suggest obsoleting 32-bit hppa-hpux support in GCC 
(install.texi says "We require using gas/binutils on all hppa 
platforms.").  (If the pre-ELF OpenBSD ports were also removed, that would 
leave pdp11 as the only GCC port defining TARGET_HAVE_NAMED_SECTIONS to 
false.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating and removing old targets

[Tristan Gingold]

> On 13 Sep 2016, at 18:26, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 13 Sep 2016, Jeff Law wrote:
> 
>> We might consider dropping hppa-som, which is an HPUX 32 bit only object
>> format.  We'd keep ELF for the linux port.
> 
> Which would suggest obsoleting 32-bit hppa-hpux support in GCC 
> (install.texi says "We require using gas/binutils on all hppa 
> platforms.").

hppa-hpux deprecation in gcc was already suggested.
But I think John David Anglin (in CC:) still maintain it.  Is that correct ?

>  (If the pre-ELF OpenBSD ports were also removed, that would 
> leave pdp11 as the only GCC port defining TARGET_HAVE_NAMED_SECTIONS to 
> false.)

Humm, not sure about XCOFF (powerpc aix).  XCOFF certainly support gc-section,
but not arbitrary named sections.

Re: Deprecating and removing old targets

[John David Anglin]

On 2016-09-14, at 3:11 AM, Tristan Gingold wrote:

> 
>> On 13 Sep 2016, at 18:26, Joseph Myers <joseph@codesourcery.com> wrote:
>> 
>> On Tue, 13 Sep 2016, Jeff Law wrote:
>> 
>>> We might consider dropping hppa-som, which is an HPUX 32 bit only object
>>> format.  We'd keep ELF for the linux port.
>> 
>> Which would suggest obsoleting 32-bit hppa-hpux support in GCC 
>> (install.texi says "We require using gas/binutils on all hppa 
>> platforms.").
> 
> hppa-hpux deprecation in gcc was already suggested.
> But I think John David Anglin (in CC:) still maintain it.  Is that correct ?

Yes.  I am currently maintaining hppa-hpux11 and hppa-linux in gcc and binutils.  hpux10 and earlier
could be deprecated.  Regarding gdb, I wasn't aware of its removal until it was done.  Still, I was able to reinstall
the removed code and do an updated build a few weeks ago.  In a little over a year, nothing major had changed
to core infrastructure.

Test results hpux11.11 are regularly posted to gcc-testresults.  In my opinion, the target is more functional than it
has ever been.  I have always viewed the hpux support as essential to the linux support.  In particular, there is no
way to test hppa64 on linux and we need it for linux kernel builds.

Functionally, the main difference between the 32-bit and 64-bit hpux support is libffi.  It has not been ported to 64-bit.
Test results are pretty similar and most of the SOM limitations have been worked around.  We do need collect2
for constructor support.

On Debian ports, we are near the top in the installed number of packages:
https://buildd.debian.org/status/architecture.php?a=hppa&suite=sid

Our package count has been slowly growing as bugs are fixed.  Indeed, ia64 is in worse shape than hppa due to
lack of maintainers.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: Deprecating and removing old targets

[Nick Clifton]

Hi Guys,

> On 12/09/16 08:37, Tristan Gingold wrote:
> Hello,
> 
> after a short discussion at the GNU cauldron 2016, I'd like to hear opinion about removing old targets in bfd.
> It is hard to know whether or not they are used, so if you are using an old target please speak up.

Just to be clear, in case anyone reading Tristan email does not know
this, any targets that we do decide to remove would first be added to
the obsolete targets list (in bfd/config.bfd), and only once a major
release has happened (probably 2.28 in this case), would we start 
actually removing code.

For the record, I am all for removing unwanted targets, as long as we 
are reasonably sure that they really are not being used any more.

Cheers
  Nick

Re: Deprecating and removing old targets

[Jose E. Marchesi]

    
    > On 12/09/16 08:37, Tristan Gingold wrote:
    > Hello,
    > 
    > after a short discussion at the GNU cauldron 2016, I'd like to hear
    > opinion about removing old targets in bfd.
    > It is hard to know whether or not they are used, so if you are using an old target please speak up.
    
    Just to be clear, in case anyone reading Tristan email does not know
    this, any targets that we do decide to remove would first be added to
    the obsolete targets list (in bfd/config.bfd), and only once a major
    release has happened (probably 2.28 in this case), would we start 
    actually removing code.

Does that mean I can remove the code for sparc*-*-rtemsaout and
sparc-*-lynxos*?  They have been listed as obsolete in config.bfd for a
long time.

It would be nice if we could get rid of the sparc-coff (only used by
lynxos AFAIK) an even the sparc-aout (old netBSD, sunos) stuff all at
once.  Only ELF sparc targets would remain..

Re: Deprecating and removing old targets

[Joel Sherrill]

On 9/14/2016 10:18 AM, Jose E. Marchesi wrote:
>
>     > On 12/09/16 08:37, Tristan Gingold wrote:
>     > Hello,
>     >
>     > after a short discussion at the GNU cauldron 2016, I'd like to hear
>     > opinion about removing old targets in bfd.
>     > It is hard to know whether or not they are used, so if you are using an old target please speak up.
>
>     Just to be clear, in case anyone reading Tristan email does not know
>     this, any targets that we do decide to remove would first be added to
>     the obsolete targets list (in bfd/config.bfd), and only once a major
>     release has happened (probably 2.28 in this case), would we start
>     actually removing code.
>
> Does that mean I can remove the code for sparc*-*-rtemsaout and
> sparc-*-lynxos*?  They have been listed as obsolete in config.bfd for a
> long time.

AFAIK RTEMS has no active targets that are not ELF. Feel free to kill
sparc*-*-rtemsaout or any target like *-*-rtemscoff* or *-*-rtemsaout*.


> It would be nice if we could get rid of the sparc-coff (only used by
> lynxos AFAIK) an even the sparc-aout (old netBSD, sunos) stuff all at
> once.  Only ELF sparc targets would remain..
>

I can't speak for LynxOS but it is a good goal.


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available                (256) 722-9985

Re: Deprecating and removing old targets

[Jeff Law]

On 09/14/2016 10:46 AM, Joel Sherrill wrote:
>
>
> On 9/14/2016 10:18 AM, Jose E. Marchesi wrote:
>>
>>     > On 12/09/16 08:37, Tristan Gingold wrote:
>>     > Hello,
>>     >
>>     > after a short discussion at the GNU cauldron 2016, I'd like to hear
>>     > opinion about removing old targets in bfd.
>>     > It is hard to know whether or not they are used, so if you are
>> using an old target please speak up.
>>
>>     Just to be clear, in case anyone reading Tristan email does not know
>>     this, any targets that we do decide to remove would first be added to
>>     the obsolete targets list (in bfd/config.bfd), and only once a major
>>     release has happened (probably 2.28 in this case), would we start
>>     actually removing code.
>>
>> Does that mean I can remove the code for sparc*-*-rtemsaout and
>> sparc-*-lynxos*?  They have been listed as obsolete in config.bfd for a
>> long time.
>
> AFAIK RTEMS has no active targets that are not ELF. Feel free to kill
> sparc*-*-rtemsaout or any target like *-*-rtemscoff* or *-*-rtemsaout*.
>
>
>> It would be nice if we could get rid of the sparc-coff (only used by
>> lynxos AFAIK) an even the sparc-aout (old netBSD, sunos) stuff all at
>> once.  Only ELF sparc targets would remain..
>>
>
> I can't speak for LynxOS but it is a good goal.
LynxOS?  Like as in the one from the early/mid 90s?  IF so, I'd suggest 
dropping it.  It was a horrid piece of junk and I'd be amazed if anyone 
is still using that garbage.

Jeff

Re: Deprecating and removing old targets

[Joel Sherrill]

On 9/14/2016 11:52 AM, Jeff Law wrote:
> On 09/14/2016 10:46 AM, Joel Sherrill wrote:
>>
>>
>> On 9/14/2016 10:18 AM, Jose E. Marchesi wrote:
>>>
>>>     > On 12/09/16 08:37, Tristan Gingold wrote:
>>>     > Hello,
>>>     >
>>>     > after a short discussion at the GNU cauldron 2016, I'd like to hear
>>>     > opinion about removing old targets in bfd.
>>>     > It is hard to know whether or not they are used, so if you are
>>> using an old target please speak up.
>>>
>>>     Just to be clear, in case anyone reading Tristan email does not know
>>>     this, any targets that we do decide to remove would first be added to
>>>     the obsolete targets list (in bfd/config.bfd), and only once a major
>>>     release has happened (probably 2.28 in this case), would we start
>>>     actually removing code.
>>>
>>> Does that mean I can remove the code for sparc*-*-rtemsaout and
>>> sparc-*-lynxos*?  They have been listed as obsolete in config.bfd for a
>>> long time.
>>
>> AFAIK RTEMS has no active targets that are not ELF. Feel free to kill
>> sparc*-*-rtemsaout or any target like *-*-rtemscoff* or *-*-rtemsaout*.
>>
>>
>>> It would be nice if we could get rid of the sparc-coff (only used by
>>> lynxos AFAIK) an even the sparc-aout (old netBSD, sunos) stuff all at
>>> once.  Only ELF sparc targets would remain..
>>>
>>
>> I can't speak for LynxOS but it is a good goal.
> LynxOS?  Like as in the one from the early/mid 90s?  IF so, I'd suggest
> dropping it.  It was a horrid piece of junk and I'd be amazed if anyone
> is still using that garbage.

It is alive and well.  See http://www.lynx.com/

I just emailed one of their kernel developers who said this target
was not in use any longer. But wait for someone from their side to
confirm that.

> Jeff
> \

--joel

Re: Fwd: Re: Deprecating and removing old targets

[Steve Bartolomei]

Jose,

Please feel free to get rid of the sparc and 68K targets.
We don't expect to have any customers looking for updates for
either of those platforms.

Thanks,
Steve Bartolomei

On 9/14/2016 9:47 AM, Joel Sherrill wrote:
> Hi
>
> This came across the binutils mailing list. I don't know
> if you guys have anyone tracking this list.  Someone
> from your side should speak up.
>
> --joel
>
>
> -------- Forwarded Message --------
> Subject: Re: Deprecating and removing old targets
> Date: Wed, 14 Sep 2016 10:18:01 -0500
> From: Jose E. Marchesi <jose.marchesi@oracle.com>
> To: Nick Clifton <nickc@redhat.com>
> CC: Tristan Gingold <gingold@adacore.com>, binutils <binutils@sourceware.org>
>
>         > On 12/09/16 08:37, Tristan Gingold wrote:
>     > Hello,
>     >
>     > after a short discussion at the GNU cauldron 2016, I'd like to hear
>     > opinion about removing old targets in bfd.
>     > It is hard to know whether or not they are used, so if you are using an 
> old target please speak up.
>         Just to be clear, in case anyone reading Tristan email does not know
>     this, any targets that we do decide to remove would first be added to
>     the obsolete targets list (in bfd/config.bfd), and only once a major
>     release has happened (probably 2.28 in this case), would we start
>     actually removing code.
>
> Does that mean I can remove the code for sparc*-*-rtemsaout and
> sparc-*-lynxos*?  They have been listed as obsolete in config.bfd for a
> long time.
>
> It would be nice if we could get rid of the sparc-coff (only used by
> lynxos AFAIK) an even the sparc-aout (old netBSD, sunos) stuff all at
> once.  Only ELF sparc targets would remain..
>

Re: Deprecating and removing old targets

[Maciej W. Rozycki]

On Mon, 12 Sep 2016, Tristan Gingold wrote:

> * all ecoff targets (alpha and mips)

 The ECOFF format is used by some old MIPS firmware for bootable images.  

 People have usually been using a third-party `elf2ecoff' tool rather than 
our `objcopy' to convert binaries, but I still think it makes sense to 
keep support in BFD so that images already made can be examined or there's 
an alternative conversion method available, in case of troubles or just 
for general interest.

 NB MIPS/ECOFF support has already been removed from GAS, LD and GDB, it's 
just binutils/ that has it still retained.  That makes it a tad of a 
challenge of course to verify remaining support hasn't regressed.

  Maciej

Re: Deprecating and removing old targets

[Tristan Gingold]

> On 28 Sep 2016, at 04:35, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> 
> On Mon, 12 Sep 2016, Tristan Gingold wrote:
> 
>> * all ecoff targets (alpha and mips)
> 
> The ECOFF format is used by some old MIPS firmware for bootable images.  

Ok.  I suppose that the mips*-*-ecoff* triplet is concerned.
What about mips*-dec-*, mips*el-*-ecoff and others ?

Tristan.

Re: Deprecating and removing old targets

[Maciej W. Rozycki]

On Wed, 28 Sep 2016, Tristan Gingold wrote:

> >> * all ecoff targets (alpha and mips)
> > 
> > The ECOFF format is used by some old MIPS firmware for bootable images.  
> 
> Ok.  I suppose that the mips*-*-ecoff* triplet is concerned.
> What about mips*-dec-*, mips*el-*-ecoff and others ?

 I think there might been a slight misunderstanding on my side; sorry 
about that.

 I believe we can actually dump all the MIPS target triplets which only 
select ECOFF vectors (and then any orphaned ECOFF vectors, i.e. 
`mips_ecoff_bele_vec', based on a quick check), but we do want to keep the 
ECOFF vectors themselves that are used as secondaries with the remaining 
MIPS target triplets.

 Similarly we can dump IRIX target triplets, however we do want to keep 
their internals across all our programs as the IRIX ELF format variation 
is used by some bare metal targets.

 So FAOD I'm fine with deprecating all these triplets right now (and then 
removing them if no one speaks up with a need for any, presumably by the 
second next release).

  Maciej

Re: Deprecating and removing old targets

[Nick Clifton]

Hi Harry,

> What is the protocol for submitting patches and what are the requirements, etc?

The code in the patches should follow the GNU Coding standard:

  http://savannah.gnu.org/projects/gnustandards

If the patch is "legally significant" (ie non trivial) then we 
must have an FSF binutils copyright assignment from you before 
we can accept the patch:

  http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

Patches should be submitted to this mailing list in the form of 
context diffs.  They should be accompanied by a proposed entry
for the ChangeLog(s) of the directories affected, in plain text
format.  (Not as a diff please as diffs to changelogs almost
never apply cleanly).

A patch should be accompanied by an explanation of what it does
and why it is necessary.  If relevant the inclusion of a new 
testcase (or two) is always appreciated.  Also if relevant you
should mention how the patch was tested and what regressions, if
any, were caused by the patch.

Oh, and thanks very much for considering contributing to this project.

Cheers
  Nick

Re: Deprecating and removing old targets

[Harry Reed]

OK, I can do that. What is the protocol for submitting patches and what 
are the requirements, etc?


Regards,

Harry Reed


On 11/04/2016 01:14 AM, Tristan Gingold wrote:
>> On 03 Nov 2016, at 18:10, Harry Reed <doon386@gmail.com> wrote:
>>
>> All,
>>
>> I've been a lurker here for a while, but decided now to chime in. The old National Semiconductor ns32k CPU lives on as a recent FPGA (re)implementation - (see: http://cpu-ns32k.net/ and http://opencores.org/project,m32632).   The ns32k was mentioned as a candidate for removal, but I would like to request that it stay due to the resurrection of this old friend.
>>
>> If you need a volunteer for maintaining the ns32k port I'll happily step-in.
> What about submitting a first patch that un-deprecates it ?
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Deprecating and removing old targets

[Tristan Gingold]

> On 03 Nov 2016, at 18:10, Harry Reed <doon386@gmail.com> wrote:
> 
> All,
> 
> I've been a lurker here for a while, but decided now to chime in. The old National Semiconductor ns32k CPU lives on as a recent FPGA (re)implementation - (see: http://cpu-ns32k.net/ and http://opencores.org/project,m32632).   The ns32k was mentioned as a candidate for removal, but I would like to request that it stay due to the resurrection of this old friend.
> 
> If you need a volunteer for maintaining the ns32k port I'll happily step-in.

What about submitting a first patch that un-deprecates it ?

Re: Deprecating and removing old targets

[Harry Reed]

All,

I've been a lurker here for a while, but decided now to chime in. The 
old National Semiconductor ns32k CPU lives on as a recent FPGA 
(re)implementation - (see: http://cpu-ns32k.net/ and 
http://opencores.org/project,m32632).   The ns32k was mentioned as a 
candidate for removal, but I would like to request that it stay due to 
the resurrection of this old friend.

If you need a volunteer for maintaining the ns32k port I'll happily 
step-in.

Regards,
Harry Reed

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus