From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29307 invoked by alias); 23 Oct 2003 03:58:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29300 invoked from network); 23 Oct 2003 03:58:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 23 Oct 2003 03:58:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ACWcX-0001Dj-O0; Wed, 22 Oct 2003 23:58:45 -0400 Date: Thu, 23 Oct 2003 03:58:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Simplify target stack Message-ID: <20031023035845.GA4655@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3F8DCC3A.4030201@redhat.com> <20031016131613.GB14202@nevyn.them.org> <3F8EB8F8.7040700@redhat.com> <20031016230710.GB1542@nevyn.them.org> <3F8F3610.2090407@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8F3610.2090407@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00684.txt.bz2 On Thu, Oct 16, 2003 at 08:21:36PM -0400, Andrew Cagney wrote: > >I believe that the objectives here are: > >> > >>1. being able to directly walk the target chain > >>Makes it possible to eliminate the INHERIT mess. Lets targets > >>efficiently/directly interact with target-beneath. > >> > >>2. allow multiple instances of a specific target > >>So that more than one target stack is possible. > >> > >>3. strict separation of target instance and target ops > >>See below. > >> > >>In terms of priority, I rank them as above. > > > > > >But we already _have_ a separation of target instance and target ops. > >It's struct target_stack_item. It's your cleanup right there, waiting > >to happen. Removing it is not a step forwards; you can just change to > >passing that item around instead of struct target_ops. If you want a > >different name, rename it. Not everywhere will need to be converted, > >obviously - only things which want the new data. > > What you're casually dismissing as trivial: "Not everywhere will need to > be converted" and "Eventually, with low urgency, the non-ops should be > moved out of it" are exactly the things I also need *now*. > > Given this, folding the two structures into-one provides me with the > shortest path to this objective. > > >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. This is standard practice for keeping the code maintainable, and evolving towards improved organization. I see that you've checked this patch in despite my objections. 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer