From: Christopher Yeoh <cyeoh@samba.org>
To: "Geoff Gustafson" <geoff@linux.co.intel.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] Open POSIX Test Suite
Date: Tue, 5 Nov 2002 14:35:14 +1100 [thread overview]
Message-ID: <15815.15474.340596.779207@gargle.gargle.HOWL> (raw)
In-Reply-To: <016601c28464$6f6d1110$7fd40a0a@amr.corp.intel.com>
At 2002/11/4 16:44-0800 Geoff Gustafson writes:
> One issue is that this new project is primarily concerned with
> testing parts of the spec that have not been fully supported in
> Linux so far. These are the kind of things that are not included in
> LSB yet, so they wouldn't be appropriate in LSB's test suite.
Actually we do include some areas that aren't yet in the LSB spec or
fully supported by Linux (eg aio) in the LSB test suites we release -
they just aren't run by default - but it is easy to enable them.
> utterly minimal. So far, each test case has its own main() function
> and a bare minimum of surrounding code. The idea is that when a bug
> is found, this one .c file can be sent to the appropriate developer,
> and without any learning curve, they have the ability to find their
> bug. I don't think LKML wants to see TET code posted here. :)
Yes, I agree TET does have a significant learning curve, and I do end
up writing small test programs that don't include the TET stuff before
sending off bug reports.
I have however seen some advantages - It is nice when you get a test
failure the report tells you exactly which part of the specification
you're violating. Once you do understand the TET/vsxgen library calls
testcases look much simpler - and if you're aiming for complete
functionality coverage including all the tricky corner cases for
various interfaces which can require quite a bit of setup code to get
into the right situation I think you'll end up having to write helper
libraries anyway.
Chris
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
next prev parent reply other threads:[~2002-11-05 3:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-04 22:48 [ANNOUNCE] Open POSIX Test Suite Geoff Gustafson
2002-11-04 22:58 ` Larry McVoy
2002-11-04 23:17 ` Geoff Gustafson
2002-11-04 23:14 ` RFC: A POSIX Linux project? Jeff Garzik
2002-11-04 23:31 ` Andreas Dilger
2002-11-04 23:51 ` Jim Freeman
2002-11-05 0:14 ` Geoff Gustafson
2002-11-05 2:01 ` Geoff Gustafson
2002-11-04 23:37 ` Rik van Riel
2002-11-05 1:14 ` Geoff Gustafson
2002-11-04 23:57 ` [ANNOUNCE] Open POSIX Test Suite Christopher Yeoh
2002-11-05 0:44 ` Geoff Gustafson
2002-11-05 2:26 ` Andreas Dilger
2002-11-05 3:35 ` Christopher Yeoh [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-11-04 23:29 Dan Kegel
2002-11-05 0:04 ` Geoff Gustafson
2002-11-05 0:08 ` Dan Kegel
2002-11-05 0:24 ` Dan Kegel
2002-11-05 3:18 ` Christopher Yeoh
2002-11-05 15:44 ` Nathan Straz
2002-11-05 15:49 Stephanie Glass
2002-11-05 16:43 ` Rusty Lynch
2002-11-05 18:24 Stephanie Glass
2002-11-05 19:05 ` Rusty Lynch
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=15815.15474.340596.779207@gargle.gargle.HOWL \
--to=cyeoh@samba.org \
--cc=geoff@linux.co.intel.com \
--cc=linux-kernel@vger.kernel.org \
/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