From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24784 invoked by alias); 17 Oct 2003 00:21:53 -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 24777 invoked from network); 17 Oct 2003 00:21:52 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 17 Oct 2003 00:21:52 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B85872B89; Thu, 16 Oct 2003 20:21:36 -0400 (EDT) Message-ID: <3F8F3610.2090407@gnu.org> Date: Fri, 17 Oct 2003 00:21:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Simplify target stack References: <3F8DCC3A.4030201@redhat.com> <20031016131613.GB14202@nevyn.them.org> <3F8EB8F8.7040700@redhat.com> <20031016230710.GB1542@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00580.txt.bz2 > 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. Andrew