From: cgd@broadcom.com
To: fche@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] make MIPS sim mips.igen model names one per line.
Date: Mon, 11 Feb 2002 13:44:00 -0000 [thread overview]
Message-ID: <yov5eljrae31.fsf@broadcom.com> (raw)
In-Reply-To: fche@redhat.com's message of "11 Feb 2002 16:18:47 -0500"
At 11 Feb 2002 16:18:47 -0500, fche@redhat.com wrote:
> cgd@broadcom.com writes:
> I must admit I don't see the point of this specific grasp for
> consistency. The single-line format allows compactness; the
> multi-line format allows greps and other line-by-line source
> manipulations. These are both useful in their place.
In this case, I fail to see how _mixing_ them in mips.igen for a
single set of ISAs (the standars mipsI ... mipsIV, and soon to be
mips32, mips64), is the right thing.
One way or the other, I think it should be consistent at least for the
MIPS ISA 'models'. There's no reason to have inconsistency.
> Have you actually encountered the maintainability issues you mention
> ([more?] "conflicts/patched lines")? Were they really troublesome?
> Given the preferred use of context diffs, it doesn't seem like
>
> A
> B
> CHANGE
> D
> E
>
> is any less likely to get conflicts than
>
> A,B
> CHANGE
> D,E
I think we've seen _a little_ in terms of that, but really it's not
been _too_ large a problem because, uh, hardly anybody has changed the
code in a long time. 8-)
I think I've heard some people (at RH, adding new model names to the
sim stuff) indicate that one-per-line is better for them. That was
like a year and a quarter ago, though, so maybe i'm misremembering.
It can actually help in practice to reduce cvs merge conflicts.
Consider:
A
B
C
modified by one person to be:
A
NEW_1
B
C
and modified by another to be:
A
B
NEW_2
C
CVS will resolve properly w/o a conflict.
in mips.igen, there typically _will_ be lines between added model name
lines, because normally you have:
<mips isas, one per line or many per line>
<one vendor's models>
<another vendor's models>
<another vendor's models>
etc. and often if you're working independently you're adding things to
different vendor model lists. (Of course, as it is now, those are
already one-per-line.)
So, in a nutshell:
(1) it can help some in general,
(2) the place where it would help most is already one-per-line,
(3) right now, for the stock MIPS ISAs 'models', the usage is mixed,
and there's no reason for that.
(4) there _is_ a bit of benefit to having one per-line even for the
stock MIPS ISAs. Eric's going to be folding in the mips32/mips64
stuff soon. I've got similar changes, and also mipsV changes. So
there will be some merging in the future, and having one-per-line
will help there.
Also, it's not as easy to go the other way than it is to split things
to be one per line. (My change was constructed via: :g/^\*/s;,;:^M*;g
Going the other way isn't so easy. 8-)
chris
next prev parent reply other threads:[~2002-02-11 21:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-11 12:26 cgd
2002-02-11 13:18 ` Frank Ch. Eigler
2002-02-11 13:44 ` cgd [this message]
2002-02-11 13:58 ` Andrew Cagney
2002-02-12 15:26 ` cgd
2002-02-12 16:31 ` Andrew Cagney
2002-02-19 0:10 ` cgd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yov5eljrae31.fsf@broadcom.com \
--to=cgd@broadcom.com \
--cc=fche@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox