From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26335 invoked by alias); 8 Jan 2003 20:18:22 -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 26265 invoked from network); 8 Jan 2003 20:18:17 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Jan 2003 20:18:17 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 949413EC2; Wed, 8 Jan 2003 15:18:19 -0500 (EST) Message-ID: <3E1C878B.2050607@redhat.com> Date: Wed, 08 Jan 2003 20:18:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/i386] Make codestream deprecated? References: <3DEAAB57.4070609@redhat.com> <86bs3yoxc7.fsf@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00336.txt.bz2 > 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.'' 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. On the other hand, if the code is clearly marked as deprecated, it clarifies this situtation - a patch either clearly is or isn't using/copying a deprecated mechanism - go directly to goal, do not pass go, do not submit patch :-) So ok? enjoy, Andrew