Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Simplify target stack
Date: Thu, 23 Oct 2003 05:06:00 -0000	[thread overview]
Message-ID: <3F9761C5.1040508@gnu.org> (raw)
In-Reply-To: <20031023035845.GA4655@nevyn.them.org>

>> > Just because you can avoid doing it now doesn't mean that's OK.  You
>> >tell that to other developers at every opportunity.
> 
>> 
>> And given a set of alternatives I'll take the one with the greatest bang 
>> for the buck.
> 
> 
> Please don't pretend I'm the only one on this list who has asked for a
> contributor to take the longer way to a goal, in light of later
> cleanups.

I'm not.  I try to apply the `bang for the buck' rule evenly to both 
myself and to others.

For instance, given the choice of asking JeffJ to add a new 
LESS_THAN_SPECIAL architecture method (+ test + doco + ...) xor just 
tighten comments in frame.h, I chose the latter.  A full analysis of the 
problem revealed that the former and zero bang for the buck!

> This is standard practice for keeping the code maintainable,
> and evolving towards improved organization.

There's a balance.  Er to much towards features and code quality goes 
down.  Er to much towards structural perfection, and new features are 
never added.

You'll note that so far, as part of getting PPC64 linux working, I've 
also: fixed struct return, and elimininated the need for a redundant 
architecture method.

> I see that you've checked this patch in despite my objections.

I thought that I had clearly stated the rationale for ordering the 
development the way I had.  That left me, as target vector maintainer, 
and the person willing to do the immediate work, with a judgment call.

> Please
> let me know when you're done with modifying the target vector for a few
> days and I'll just separate instance and ops myself, including moving
> the new to_beneath and to_data fields out of struct target_ops.

It will be a lot more than a few days :-(  And if you wait long enough, 
I'll likely to do it myself!

Andrew



  reply	other threads:[~2003-10-23  5:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-15 22:37 Andrew Cagney
2003-10-16 13:16 ` Daniel Jacobowitz
2003-10-16 15:27   ` Andrew Cagney
2003-10-16 23:07     ` Daniel Jacobowitz
2003-10-17  0:21       ` Andrew Cagney
2003-10-23  3:58         ` Daniel Jacobowitz
2003-10-23  5:06           ` Andrew Cagney [this message]
2003-10-17 13:57 ` Andrew Cagney

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=3F9761C5.1040508@gnu.org \
    --to=cagney@gnu.org \
    --cc=drow@mvista.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