Subject: Re: Regressing testing of system calls
To: Chris G. Demetriou <cgd@netbsd.org>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-kern
Date: 06/15/1999 11:19:06
In some email I received from Chris G. Demetriou, sie wrote:
> 
> Darren Reed <darrenr@reed.wattle.id.au> writes:
> > To do this testing,
> > I'm using the list of errors on the man page for each system call and
> > attempting to call them (with an appropriate environment) in such a way
> > that they do fail as described.  Given some of the comments people have
> > made about what manual pages are meant to document, I'm pondering whether
> > or not this is the `correct' approach.
> 
> I'm not convinced it is.

I'm open to suggestion for other methods to achieve the same goal.

> first of all, there's the issue of conditions which may or may not be
> detected as part of the code run in the kernel (e.g. the EFAULT
> vs. SEGV), which you've already noticed.  i.e. you're checking error
> input vs. guaranteed type of error return, which is backwards (at
> least for some types of bogus input).

In some sense, "input" is more than just parameters passed to system
calls.

> there are also other issues where the manual pages are simply not
> complete, and therefore your testing will not be complete if you just
> follow the manual pages.

Then this is an issue for documentation to be corrected.  I don't see
how one can reasonably test something that isn't documented.

> For instance, consider read():
> 
>      [EFAULT]      buf points outside the allocated address space.
> 
> Depending on how you're reading these things, either:
> 
> 	(1) you wouldn't check for reading into a buffer in the
> 	    address space but mapped read-only (e.g. read(0, &main, 1); 8-)

Does this in fact cause the above error ?

> 	(2) the kernel would be considered 'broken' to return EFAULT
> 	    for that case.

I'd agree with this, but given this, what should it return ?

> If you want to do this kind of testing, personally, i'd think you're
> best off either starting with a POSIX (or other) conformance test
> suite, or at least a standards document, and going from there, and, if
> necessary, fixing up the manual pages as you go to match.

Is there a POSIX conformance test suite or can someone pass along where I
can get the relevant standards document ?  Hmmm, if we did go down this
path, does it lead to us being able to say we are POSIX compliant ?

Darren