From: Nicholas Nethercote <n.nethercote@gmail.com>
Date: Wed, 16 Jun 2004 11:51:08 +0000 (+0000)
Subject: Removed documentation references to the 'ioctl-VTIME' and 'truncate-writes'
X-Git-Tag: svn/VALGRIND_2_1_2~88
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=63c632f5f3c8b2337c396e73bb810edac57fa5a8;p=thirdparty%2Fvalgrind.git

Removed documentation references to the 'ioctl-VTIME' and 'truncate-writes'
weird hacks, which no longer exist thanks to the proxy lwp stuff.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2419
---

diff --git a/coregrind/docs/coregrind_core.html b/coregrind/docs/coregrind_core.html
index 34edcf2425..0a01661b03 100644
--- a/coregrind/docs/coregrind_core.html
+++ b/coregrind/docs/coregrind_core.html
@@ -779,58 +779,6 @@ the Valgrind core.  Most people won't need to use these.
       are enabled.  Use with caution!  Currently known hacks are:
       <p>
       <ul>
-      <li><code>ioctl-VTIME</code> Use this if you have a program
-          which sets readable file descriptors to have a timeout by
-          doing <code>ioctl</code> on them with a
-          <code>TCSETA</code>-style command <b>and</b> a non-zero
-          <code>VTIME</code> timeout value.  This is considered
-          potentially dangerous and therefore is not engaged by
-          default, because it is (remotely) conceivable that it could
-          cause threads doing <code>read</code> to incorrectly block
-          the entire process.
-          <p>
-          You probably want to try this one if you have a program
-          which unexpectedly blocks in a <code>read</code> from a file
-          descriptor which you know to have been messed with by
-          <code>ioctl</code>.  This could happen, for example, if the
-          descriptor is used to read input from some kind of screen
-          handling library.
-          <p>
-          To find out if your program is blocking unexpectedly in the
-          <code>read</code> system call, run with
-          <code>--trace-syscalls=yes</code> flag.
-      <p>
-      <li><code>truncate-writes</code> Use this if you have a threaded
-          program which appears to unexpectedly block whilst writing
-          into a pipe.  The effect is to modify all calls to
-          <code>write()</code> so that requests to write more than
-          4096 bytes are treated as if they only requested a write of
-          4096 bytes.  Valgrind does this by changing the
-          <code>count</code> argument of <code>write()</code>, as
-          passed to the kernel, so that it is at most 4096.  The
-          amount of data written will then be less than the client
-          program asked for, but the client should have a loop around
-          its <code>write()</code> call to check whether the requested
-          number of bytes have been written.  If not, it should issue
-          further <code>write()</code> calls until all the data is
-          written.
-          <p>
-          This all sounds pretty dodgy to me, which is why I've made
-          this behaviour only happen on request.  It is not the
-          default behaviour.  At the time of writing this (30 June
-          2002) I have only seen one example where this is necessary,
-          so either the problem is extremely rare or nobody is using
-          Valgrind :-)
-          <p>
-          On experimentation I see that <code>truncate-writes</code>
-          doesn't interact well with <code>ioctl-VTIME</code>, so you
-          probably don't want to try both at once.
-          <p>
-          As above, to find out if your program is blocking
-          unexpectedly in the <code>write()</code> system call, you
-          may find the <code>--trace-syscalls=yes
-          --trace-sched=yes</code> flags useful.
-      <p>
       <li><code>lax-ioctls</code> Be very lax about ioctl handling; the only
           assumption is that the size is correct. Doesn't require the full
           buffer to be initialized when writing.  Without this, using some
diff --git a/coregrind/vg_main.c b/coregrind/vg_main.c
index a02b930000..a9181a6baa 100644
--- a/coregrind/vg_main.c
+++ b/coregrind/vg_main.c
@@ -1520,7 +1520,7 @@ void usage ( Bool debug_help )
 "  uncommon user options for all Valgrind tools:\n"
 "    --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
 "    --weird-hacks=hack1,hack2,...  [none]\n"
-"         recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls\n"
+"         recognised hacks are: lax-ioctls\n"
 "    --signal-polltime=<time>  time, in mS, we should poll for signals.\n"
 "                              Only applies for older kernels which need\n"
 "                              signal routing [50]\n"
diff --git a/none/tests/cmdline1.stdout.exp b/none/tests/cmdline1.stdout.exp
index c814b03493..751eb8fb80 100644
--- a/none/tests/cmdline1.stdout.exp
+++ b/none/tests/cmdline1.stdout.exp
@@ -13,7 +13,7 @@ usage: valgrind --tool=<toolname> [options] prog-and-args
   uncommon user options for all Valgrind tools:
     --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
     --weird-hacks=hack1,hack2,...  [none]
-         recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
+         recognised hacks are: lax-ioctls
     --signal-polltime=<time>  time, in mS, we should poll for signals.
                               Only applies for older kernels which need
                               signal routing [50]
diff --git a/none/tests/cmdline2.stdout.exp b/none/tests/cmdline2.stdout.exp
index 3c5cdb4593..1d96483292 100644
--- a/none/tests/cmdline2.stdout.exp
+++ b/none/tests/cmdline2.stdout.exp
@@ -13,7 +13,7 @@ usage: valgrind --tool=<toolname> [options] prog-and-args
   uncommon user options for all Valgrind tools:
     --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
     --weird-hacks=hack1,hack2,...  [none]
-         recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls
+         recognised hacks are: lax-ioctls
     --signal-polltime=<time>  time, in mS, we should poll for signals.
                               Only applies for older kernels which need
                               signal routing [50]