From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([66.187.233.31]:52529 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbXLUIwv (ORCPT ); Fri, 21 Dec 2007 03:52:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath Subject: Re: [PATCH -mm 09/43] compat_sys_ptrace In-Reply-To: Christoph Hellwig's message of Friday, 21 December 2007 07:11:02 +0000 <20071221071102.GB4345@infradead.org> References: <20071220115200.C767E26F98A@magilla.localdomain> <20071220115551.73EE026F98B@magilla.localdomain> <20071221071102.GB4345@infradead.org> Message-Id: <20071221085216.30E4726F98A@magilla.localdomain> Date: Fri, 21 Dec 2007 00:52:16 -0800 (PST) Sender: linux-arch-owner@vger.kernel.org List-ID: To: Christoph Hellwig Cc: Andrew Morton , Linus Torvalds , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org > Nice, we should have unified the compat ptrace code long ago. There is still more consolidation that can be done, but this is a first step. > Any chance you could make the ifdef symetric to the native ptrace > where an arch defines a symbol if it has it's own ptrace? That would require touching each and every arch's headers so as not to break it with the generic changes. I seem to get berated for that sort of thing more often than asked for it. > Also when prototyping something like this I was wondering whether we > really want a separate compat function. Lots of the ptrace requests > mostly depend on the target processes abi, not the ptrace caller, [...] That's not really true of any ptrace request that isn't already wholly arch-dependent, and not true of any majority of those either. For all of the things that are likely to be handled in generic code any time soon, it's the caller of ptrace whose natural data formats reign. > [...] Anyway, that's probably something to worry about > later one the arch-specific compat ptrace implementations are gone. Indeed. Thanks, Roland