From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964882AbWDZVaC (ORCPT ); Wed, 26 Apr 2006 17:30:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964885AbWDZVaB (ORCPT ); Wed, 26 Apr 2006 17:30:01 -0400 Received: from filer.fsl.cs.sunysb.edu ([130.245.126.2]:65250 "EHLO filer.fsl.cs.sunysb.edu") by vger.kernel.org with ESMTP id S964882AbWDZVaB (ORCPT ); Wed, 26 Apr 2006 17:30:01 -0400 Subject: Re: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK From: "Charles P. Wright" To: Jeff Dike Cc: Bodo Stroesser , Heiko Carstens , linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net In-Reply-To: <20060426194009.GA9845@ccure.user-mode-linux.org> References: <200604131720.k3DHKqdr004720@ccure.user-mode-linux.org> <20060420090514.GA9452@osiris.boeblingen.de.ibm.com> <444797F8.6020509@fujitsu-siemens.com> <1146083202.10211.1.camel@localhost.localdomain> <20060426194009.GA9845@ccure.user-mode-linux.org> Content-Type: text/plain Date: Wed, 26 Apr 2006 17:29:53 -0400 Message-Id: <1146086993.10851.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2006-04-26 at 15:40 -0400, Jeff Dike wrote: > On Wed, Apr 26, 2006 at 04:26:42PM -0400, Charles P. Wright wrote: > > I have a similar local patch that I've been using. I think it would be > > worthwhile to have an extra bit in the bitmap that says what to do with > > calls that fall outside the range [0, __NR_syscall]. That way the > > ptrace monitor can decide whether it is useful to get informed of these > > "bogus" calls. > > The bit needs to be somewhere, but I think sticking it in the syscall > bitmask is a bad idea. Mixing apples and oranges, as it were. > Sticking it in the op is better, even though that's a bit of apples > and oranges as well. > > Another alternative would be to make it an option and set it with > PTRACE_SETOPTIONS. That is probably a better solution than sticking it in the request (I assume you meant request by op). I think spawning more PTRACE_* requests that perform some permutation of PTRACE_SYSCALL is likely to make things confusing. Charles