assembler routines obsolete. Be more exhaustive by testing dynamically
linked, statically linked and dynamically loaded.
XXX currently hard-codes /usr/tests due to limitations of bsd.test.mk
How it works:
NFS tests fork and exec the nfs service from fs/nfs/nfsservice.
The child then:
a) creates a FFS file system
b) mounts it
c) starts rpcbind
d) starts mountd
e) starts nfsd
f) handles requests
The client, as expected, does the standard RPC regotiation and
calls mount(MOUNT_NFS). It then proceeds to execute the test.
An individual test which executes everything described above and
does a few file operations on the NFS mount takes 0.16s wall time
on my laptop from start to finish. This means it is feasible to
run hundreds of tests while still getting results in a timely
fashion.
Like in other networked tests, the two processes are connected via
the rump shmif which uses mmapped files as ethernet busses. The
entire test suite can be executed by an unprivileged account.
As a side effect, these tests exercise also the kernel NFS server
in addition to the kernel NFS client.
While everything is currently targetted at executing the vfs tests,
there is no reason this could not be extended to exercise features
specific to NFS. For example, the server can run through all
exportable file system types, permissions can be tested, etc.
as an xfail everywhere and, while doing so, make the test longer so that
we trigger the failure all the time -- of course, being a race this may
still happen but the chances should be pretty low.
that does. The former works all the time but the latter gets consistently
stuck on amd64. Mark the latter as an expected timeout (should be a "race
condition" test, but atf does not have such a thing yet[1]).
This clears the test failures, at least, under anita running NetBSD/i386.
From pooka@: this could well be because calling sem_post(3) from a signal
handler can't possibly do the right thing with the pthread implementation.
However, according to signal(7), sem_post(3) is signal-async safe...
While here, program alarms using a timeout shorter than 1 second to speed
up the execution of the tests.
1: Good thing is I finally understand what a "race condition" test looks
like, I believe.
to validate the execution of sort(1) and do not bother removing temporary
files.
This is in preparation to merge the tests for sort(1) that still live in
regress/usr.bin/sort/stests.
atf. They break on i386 (because the test was conceptually broken anyway);
reported by pooka@ in private mail.
Now... the current test does not actually check anything AFAICT... but this
is how it was before.
