HACKING: emphasize embedded-c testing

2 files changed, 10 insertions, 6 deletions

diff --git a/HACKING b/HACKING
index 24986a9e..132794c8 100644
--- a/HACKING
+++ b/HACKING
@@ -96,11 +96,14 @@ the <systemtap@sources.redhat.com> mailing list.
   Internal function, variable, probe identifiers should be prefixed
   with "_" for extra uniqueness, and not documented in the man pages.
 
-  Tapsets should come with a tests cases that provide good test coverage.
-  Every alias definition should be tested for pass-2 correctness.  Every
-  embedded-C routine should be tested for pass-4 buildability and ideally
-  pass-5 correctness.  The platforms/architectures against which the tapset
-  was tested should be published, and ideally asserted by code.
+  Tapsets should come with a tests cases that provide good test
+  coverage.  Every alias definition should be tested for pass-2
+  correctness.  Every embedded-C routine should be tested for pass-4
+  buildability.  As they are a security hazard, every tapset
+  embedded-C routine should be pass-5 stress-tested for response to
+  erroneous inputs.  This applies doubly to /* unprivileged */ ones.
+  The platforms/architectures against which the tapset was tested
+  should be published, and ideally asserted by code.
 
   Embedded-C code should avoid making references to the runtime or
   other code possibly generated by the translator.  Embedded-C code that
diff --git a/tapset/DEVGUIDE b/tapset/DEVGUIDE
index 5d7c8658..718fadc4 100644
--- a/tapset/DEVGUIDE
+++ b/tapset/DEVGUIDE
@@ -242,7 +242,8 @@ built into SystemTap.  Be especially careful when dereferencing
 pointers.  Use the kread() macro to dereference any pointers that could
 potentially be invalid.  If you're not sure, err on the side of caution.
 The cost of using kread() is small compared to the cost of your tapset
-inadvertently crashing a system!
+inadvertently crashing a system!  It is necessary to rigorously test
+embedded-C functions in the testsuite.
 
 Add the string 
     /* pure */