From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 365 invoked by alias); 8 Jan 2003 20:31:07 -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 32766 invoked from network); 8 Jan 2003 20:30:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 20:30:57 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18WOie-0000Qw-00; Wed, 08 Jan 2003 16:30:40 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18WMqD-0001YS-00; Wed, 08 Jan 2003 15:30:21 -0500 Date: Wed, 08 Jan 2003 20:31:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [rfa/i386] Make codestream deprecated? Message-ID: <20030108203021.GA5740@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <3DEAAB57.4070609@redhat.com> <86bs3yoxc7.fsf@elgar.kettenis.dyndns.org> <3E1C878B.2050607@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1C878B.2050607@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00337.txt.bz2 On Wed, Jan 08, 2003 at 03:18:19PM -0500, Andrew Cagney wrote: > >Andrew Cagney writes: > > > > > >>2002-12-01 Andrew Cagney > >> > >> * i386-tdep.c: Replace `codestream' with `deprecated_codestream'. > > > > > >Sorry, but I'm not really enthousiastic about this patch. IMHO a > >comment explaining the reason why one shouldn't copy this bit of code > >would be much better. I'm willing to rip out this bit of code, and > >replace it with something cleaner and simpler, but this "deprication" > >is only noise to me. > > I'll add a comment. Briefly it will read: > > ``The deprecated codestream mechanism is entirely redundant. The dcache > superseeds it, providing a generic mechanism for caching both > instruction and data values. If the dcache has problems or limitations > than that, and not this code, needs to be fixed.'' Except we don't _use_ the dcache, normally. And my last attempts to enable it by default met with a pretty crummy reaction. And the last time I benchmarked using the dcache I got worse results than without it. [And you spelled supersedes incorrectly :)] > While you might think of marking this as deprecated as noice, as I noted > to Daniel, it has a very real and direct objective: > > >Been there, tried that. As best I can tell, the only thing that makes > >someone stop and think, is the word deprecated in the name. Coders don't > >always read the comments, reviewers can't keep track of everything that is > >being eliminated :-/ > > If I don't do this, I find I get a (lets say) less than favourable > reception when asking a contributor to not [re]use a mechanism > identified as deprecated via either a comment or bug report. cf, this > very code block when cloned into another architecture; or the regcache > code before I went through and marked much of that as deprecated. Maybe I just have a short memory, but when has that happened? That you've pointed out that something was marked deprecated before it was reused, and gotten a bad reception? Besides: this is why you should _remove_ them, rather than just commenting them, if you want them to go away. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer