From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: 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: Sat, 29 Apr 2006 10:49:07 +0200 [thread overview]
Message-ID: <20060429084907.GD9463@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <200604282228.46681.blaisorblade@yahoo.it>
> Ok, this gives us a definite proposal, which I finally like:
>
> * to exclude sys_tee:
>
> bitmask = 0;
> set_bit(__NR_tee, bitmask);
> ptrace(PTRACE_SET_NOTRACE, bitmask);
>
> * to trace only sys_tee:
>
> bitmask = 0;
> set_bit(__NR_tee, bitmask);
> ptrace(PTRACE_SET_TRACEONLY, bitmask);
>
> Semantics:
>
> in both cases, the mask is first zero-extended to the right (for syscalls not
> known to userspace), bits for syscall not known to the kernel are checked and
> the call fails if any of them is 1, and in the failure case E2BIG or
> EOVERFLOW is returned (I want to avoid EINVAL and ENOSYS to avoid confusion)
> and the part of the mask known to the kernel is 0-ed.
>
> In case of success, for NOTRACE (which was DEFAULT_TRACE) the mask is reversed
> before copying in the kernel syscall mask, for TRACEONLY it's copied there
> directly.
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.
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.
next prev parent reply other threads:[~2006-04-29 8:49 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 [this message]
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=20060429084907.GD9463@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=blaisorblade@yahoo.it \
--cc=bstroesser@fujitsu-siemens.com \
--cc=jdike@addtoit.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