Re: New Sanyo Stormy16 relocations

[Doug Evans <dje@transmeta.com>]

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].