MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
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-kernel-owner@vger.kernel.org
Content-Length: 1349
Lines: 34

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/