This is the mail archive of the
mailing list for the CGEN project.
Re: New Sanyo Stormy16 relocations
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.
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].