From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20602 invoked by alias); 18 Feb 2011 15:46:38 -0000 Received: (qmail 20591 invoked by uid 22791); 18 Feb 2011 15:46:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Feb 2011 15:46:33 +0000 Received: (qmail 27901 invoked from network); 18 Feb 2011 15:46:32 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Feb 2011 15:46:32 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [common] Merge duplicated macros in linux-nat.c and linux-low.c Date: Fri, 18 Feb 2011 15:52:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: Yao Qi References: <4D5E2021.2070107@codesourcery.com> In-Reply-To: <4D5E2021.2070107@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201102181546.26744.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00466.txt.bz2 One general comment I have with moving things under common/, --- just a though towards the whole sharing process itself; not on this particular patch --- is that I'd very much like us to avoid putting "common" on the filename of files we end up putting under common/. That's just redundant. Imagine we end up moving one of these files elsewhere. Then we'd need to rename them again. Or that we end up with a single implementation of the target backend (we get rid of all the linux-nat.c code, for example) --- then "common" on the filename stops making sense at that point as well. Let's name the files according to their contents instead. Let's take the opportunity to split independent things into separate files if it makes sense to factor them out. E.g., x86 watchpoint related macros -> x86-watch.h or x86-nat-watch.h or i386-watchpoint.h, or something like that, not x86-common.h. E.g., linux ptrace related macros and definition -> linux-ptrace.h or something like that. I realize that there are some files where "common" will make most sense, and we shouldn't spend time bikeshedding on filenames. This patch may well be one of those. Again, I'm speaking to the whole process, not particularly to this patch. -- Pedro Alves