9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] Regression testing
Date: Wed, 26 Mar 2014 12:25:05 -0400	[thread overview]
Message-ID: <d25e86f547317f5f5ede450bb837d772@brasstown.quanstro.net> (raw)
In-Reply-To: <CAGMcHPr1bgintE9WeFt6GbarwqLfLfOaYpx6nJqWnxm8HCR-sA@mail.gmail.com>

On Wed Mar 26 07:11:38 EDT 2014, riddler876@gmail.com wrote:

> Hello,
> 
> I would also be quite interested in helping if people are embarking on such
> a project.
> 
> I'm a Computer Science student and I've been using a raspberry pi trying to
> learn more about plan 9. Creating regression tests could be a good way for
> me to poke around the system learning how it works while still contributing
> something useful to the community.

i think this could be quite valuable.  at a minimum, you will learn alot.

i assume that you mean automated tests.  many things like usb behavior
on unplugging is hard to automate without some special equipment.

imo, the easiest thing to automate would be the system calls.  there
are very few of them.  i would first start by checking that they do reasonable
things with arguments in the text, heap, stack, and various forms of
invalid addresses, especially just above or just below valid addresses.

it is also pretty straightforward to test a the kernel devices to make sure
they all handle invalid file names/directory names well, deal with bad
input to control files well, etc.

(an idea that occurs to me while typing this is to have a special syscallmal
for allocating things with system call lifetime.  it allows one to add the rule
that everything syscallmal'd must be free'd on kernel exit.)

another area that might not be as easy (as you'll have to dive into some
obtuse stuff) would be floating point.  but this would be very helpful, because
it has been a long time since serious effort was put into this.
floating point should well behaved with the usual operations,
and with standard library functions (and ape, too), with respect to the usual problem
areas such as overflow, underflow,  -0., ±∞, and denormals, with all
fcr (see getfcr(2)) settings, and with all architectures.  or at least amd64,
rpi and something with emulated fp such as the rb.

run-on sentences 'ᴙ' us.

i'd be willing to give you some pointers on how to continue.  i have some
scripts that i used to iron some of the worst bugs out of fp so that python
could pass some regression tests.

- erik



  reply	other threads:[~2014-03-26 16:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 10:55 Pauric Ward
2014-03-26 11:10 ` Riddler
2014-03-26 16:25   ` erik quanstrom [this message]
2014-03-29 13:57     ` Riddler

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=d25e86f547317f5f5ede450bb837d772@brasstown.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.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;
as well as URLs for NNTP newsgroup(s).