Re: New Sanyo Stormy16 relocations

Re: New Sanyo Stormy16 relocations

[DJ Delorie]

> Having to get cgen approval for cpu-specific changes sucks.
> People should be able to police their own ports.
> gcc port maintainers don't have to get approval for changes to their
> ports.  I don't understand why this would be any different.

Because cgen feeds binutils, gdb, and sid.  Which one of those has the
port maintainers responsible for cgen?  What happens if a binutils
maintainer changes cgen, and unknowingly breaks sid or gdb?

> But, if approval is required, methinks binutils is a better place to
> provide approval for .opc changes (e.g. complaints about warnings :-).

Better than sid?  Better than gdb?  OTOH we've talked about moving the
port-specific files out of cgen and into their own toplevel directory,
which would remove this issue anyway.

But, let me make the formal request anyway.  gdb and sid cc'd.

Cgen folks (and others)...  would it be acceptable to change the cgen
approval rules to allow people who could otherwise approve
port-specific patches in binutils, gdb, or sid, to be allowed to
approve port-specific changes in cgen as well?

Re: New Sanyo Stormy16 relocations

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Hi -

On Tue, Dec 17, 2002 at 02:47:03PM -0500, DJ Delorie wrote:
> > Having to get cgen approval for cpu-specific changes sucks.
> > [...]
> 
> Because cgen feeds binutils, gdb, and sid.  Which one of those has the
> port maintainers responsible for cgen?  

Assuming you're referring to cgen model files as opposed to cgen scheme
sources, such port maintainers can work this out amongst themselves.
I see no need for formal process to handle this (hypothetical?) problem.


> What happens if a binutils
> maintainer changes cgen, and unknowingly breaks sid or gdb?

Then as soon as the breakage is identified, the person causing the
breakage will have to negotiate to assure some sort of correction.
No big deal.


> [...]
> But, let me make the formal request anyway.  gdb and sid cc'd.
> 
> Cgen folks (and others)...  would it be acceptable to change the cgen
> approval rules to allow people who could otherwise approve
> port-specific patches in binutils, gdb, or sid, to be allowed to
> approve port-specific changes in cgen as well?

In line with dje's hints, I have no objection, as long as people
stand behind their patch if unforseen negative effects result.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: New Sanyo Stormy16 relocations

[Doug Evans]

DJ Delorie writes:
 > > Having to get cgen approval for cpu-specific changes sucks.
 > > People should be able to police their own ports.
 > > gcc port maintainers don't have to get approval for changes to their
 > > ports.  I don't understand why this would be any different.
 > 
 > Because cgen feeds binutils, gdb, and sid.  Which one of those has the
 > port maintainers responsible for cgen?  What happens if a binutils
 > maintainer changes cgen, and unknowingly breaks sid or gdb?

[Just to be clear, the context of my remarks is changes to .cpu/.opc files.
Nothing else.]

A port maintainer is a port maintainer.

If redhat is the port maintainer for xstormy16 and checks in something to
xstormy16.cpu because they need to change binutils and later find out
they've broken gdb(sim) it's a problem of their own doing.  They can undo it.

Similarily for any port maintainer.

 > > But, if approval is required, methinks binutils is a better place to
 > > provide approval for .opc changes (e.g. complaints about warnings :-).
 > 
 > Better than sid?  Better than gdb?

I don't understand.  The context here is .opc. files.
Changes to .opc files don't affect sid or gdb.  Only binutils.

 > OTOH we've talked about moving the
 > port-specific files out of cgen and into their own toplevel directory,
 > which would remove this issue anyway.
 > 
 > But, let me make the formal request anyway.  gdb and sid cc'd.
 > 
 > Cgen folks (and others)...  would it be acceptable to change the cgen
 > approval rules to allow people who could otherwise approve
 > port-specific patches in binutils, gdb, or sid, to be allowed to
 > approve port-specific changes in cgen as well?

I'm not sure I would word it that way.  Maybe it's ok, I dunno.
uber-hackers in binutils/gdb may be able to make port specific
changes as they deem necessary (are they?).  I'm not sure this should extend
to .cpu files.  But I certainly have no problem with authorized
port maintainers of binutils/gdb making changes to cgen port-specific
files (provided of course they're willing to work through any problems
that may arise).

Given the above seemingly misunderstandings, just so we're clear,
"port-specific changes" means changes to files in src/cgen/cpu
[or whereever they move to].

Re: New Sanyo Stormy16 relocations

[Doug Evans]

Doug Evans writes:
 >  > > But, if approval is required, methinks binutils is a better place to
 >  > > provide approval for .opc changes (e.g. complaints about warnings :-).
 >  > 
 >  > Better than sid?  Better than gdb?
 > 
 > I don't understand.  The context here is .opc. files.
 > Changes to .opc files don't affect sid or gdb.  Only binutils.

[flipping the pedantic bit]
Ok, gdb uses the disassembler.
Still, if src/opcodes is ok for binutils, I don't think
it's a problem for gdb or sid.
And if it is, the problem can be dealt with as it arises.

Re: New Sanyo Stormy16 relocations

[Andrew Cagney]

>> Having to get cgen approval for cpu-specific changes sucks.
>> People should be able to police their own ports.
>> gcc port maintainers don't have to get approval for changes to their
>> ports.  I don't understand why this would be any different.
> 
> 
> Because cgen feeds binutils, gdb, and sid.  Which one of those has the
> port maintainers responsible for cgen?  What happens if a binutils
> maintainer changes cgen, and unknowingly breaks sid or gdb?
> 
> 
>> But, if approval is required, methinks binutils is a better place to
>> provide approval for .opc changes (e.g. complaints about warnings :-).
> 
> 
> Better than sid?  Better than gdb?  OTOH we've talked about moving the
> port-specific files out of cgen and into their own toplevel directory,
> which would remove this issue anyway.
> 
> But, let me make the formal request anyway.  gdb and sid cc'd.
> 
> Cgen folks (and others)...  would it be acceptable to change the cgen
> approval rules to allow people who could otherwise approve
> port-specific patches in binutils, gdb, or sid, to be allowed to
> approve port-specific changes in cgen as well?

This would only all make sense if the .opc et.al. files were all (C) 
FSF.  Which is back to my things-to-do-today list of fill out the 
src/cpu directory a little.

Andrew

Re: New Sanyo Stormy16 relocations

[Frank Ch. Eigler]

cagney wrote:

> [...]
> > Cgen folks (and others)...  would it be acceptable to change the cgen
> > approval rules to allow people who could otherwise approve
> > port-specific patches in binutils, gdb, or sid, to be allowed to
> > approve port-specific changes in cgen as well?
> 
> This would only all make sense if the .opc et.al. files were all (C)
> FSF.  [...]

Sorry, I don't see how that relates to the issue.  Regardless of whose
(C) is on the files, the current matter is which of several potential
maintainer types should feel free to commit changes.


- FChE