public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Blaisorblade <blaisorblade@yahoo.it>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK
Date: Tue, 25 Apr 2006 11:59:42 -0400	[thread overview]
Message-ID: <20060425155942.GA22807@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060422070610.GA9459@osiris.boeblingen.de.ibm.com>

On Sat, Apr 22, 2006 at 09:06:10AM +0200, Heiko Carstens wrote:
> > The flags could be:
> > 
> > MASK_DEFAULT_TRACE (set the default to 1 for remaining bits)
> > MASK_DEFAULT_IGNORE (set the default to 0 for remaining bits)
> > MASK_STRICT_VERIFY (return -EINVAL for bits exceeding NR_syscalls and set 
> > differently than the default).

I'd prefer (given that there aren't any unused ptrace arguments) using
the operation for this - PTRACE_SYSCALL_MASK_TRACE,
PTRACE_SYSCALL_MASK_IGNORE.  We'd need better names than these
horribly over-long ones, though.

> You might as well introduce yet another ptrace call which returns the number
> of system calls and for this ptrace call force user space to pass a complete
> bitmap. Sounds easier to me.

I think that's just building in fragility whenever userspace doesn't
happen to match the kernel.  Both UML and strace will know what system
calls they are interested in.  Having the kernel 1- or 0-extend the
mask will automatically do the right thing.  If userspace is newer
than the kernel, and asks for special treatment for system calls that
don't exist, then it should get a -EINVAL.

				Jeff

  parent reply	other threads:[~2006-04-25 16:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13 17:20 [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK Jeff Dike
2006-04-18 12:57 ` Pavel Machek
2006-04-26 18:38   ` Jeff Dike
2006-04-20  9:05 ` Heiko Carstens
2006-04-20 14:17   ` [uml-devel] " Bodo Stroesser
2006-04-25 18:32     ` Jeff Dike
2006-04-26 20:26     ` Charles P. Wright
2006-04-26 19:40       ` Jeff Dike
2006-04-26 21:29         ` Charles P. Wright
2006-04-21 18:16   ` Blaisorblade
2006-04-21 18:38     ` Blaisorblade
2006-04-22  7:06     ` Heiko Carstens
2006-04-22  8:32       ` Blaisorblade
2006-04-25 15:59       ` Jeff Dike [this message]
2006-04-21 18:34 ` [uml-devel] " Blaisorblade
2006-04-25 16:29   ` Jeff Dike
2006-04-26 15:47     ` Blaisorblade
2006-04-26 15:46       ` Jeff Dike
2006-04-28 20:28         ` Blaisorblade
2006-04-29  1:49           ` Jeff Dike
2006-05-01 13:51             ` Daniel Jacobowitz
2006-05-01 13:45               ` Jeff Dike
2006-05-01 15:01                 ` Daniel Jacobowitz
2006-04-29  8:49           ` Heiko Carstens
2006-05-01 17:02             ` Jeff Dike
2006-05-02  6:57               ` Heiko Carstens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060425155942.GA22807@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=blaisorblade@yahoo.it \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox