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,
	Jeff Dike <jdike@addtoit.com>,
	linux-kernel@vger.kernel.org,
	Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Subject: Re: [uml-devel] [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK
Date: Mon, 1 May 2006 13:02:33 -0400	[thread overview]
Message-ID: <20060501170233.GC4592@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060429084907.GD9463@osiris.boeblingen.de.ibm.com>

On Sat, Apr 29, 2006 at 10:49:07AM +0200, Heiko Carstens wrote:
> IMHO this is way too complicated. Introducing a ptrace call that returns
> the number of syscalls and forcing user space to pass a complete bitmask
> is much easier. Also the semantics are much easier to understand.

This sounds more complicated than what we are proposing.  

This would make the process care about the number of system calls
implemented by the kernel, which is something that doesn't even come
up in the normal case with the current interface.  You only care about
it if you get a -EINVAL and want to figure out exactly why.

>From a practical point of view, you would want code that looks like
this:
	n = nsyscalls();
	mask = malloc((n + 7)/8);
	if(mask == NULL)
		return;

	/* Zero mask, set bits, call ptrace */

	free(mask);

rather than code like this:

	int mask[(BIGGEST_SYSCALL_I_CARE_ABOUT + 7) / 8];

	/* Zero mask, set bits, call ptrace */

That doesn't seem like an improvement to me.

The second case would be more complicated if it wanted to figure out
what the problem was if ptrace returned -EINVAL.  However, some users
won't care, so that complexity is optional.  For example, UML will
already know by other means what system calls are implemented on the
host, so it won't bother looking at the mask in the case of a
failure.  I'm not sure what the right thing for strace is.

> In addition your proposal would already introduce a rather complicated
> interface to figure out how many syscalls the kernel has. I'm sure this
> will be (mis)used sooner or later.

How?  And, if so, why is that a problem?

There are already complicated ways to figure out what system calls the
kernel has, and I don't recall them causing problems.

				Jeff

  reply	other threads:[~2006-05-01 18:02 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
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 [this message]
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=20060501170233.GC4592@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=blaisorblade@yahoo.it \
    --cc=bstroesser@fujitsu-siemens.com \
    --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