more than create an empty file system, grow it, and makes sure fsck
finds the result clean. The 'shrink' test does likewise for shrinking,
but is an expected failure at the moment due to PR bin/44177.
Fun fact: since the server daemonizes into its own process group,
it's not in atf's pgrp. Use rump_sys_reboot() in atf cleanup to
kill the server after the test.
Notably, md is a little tricky for this, since the ioctl that
configures the service also blocks in the kernel. Therefore, use
an additional pthread to probe when the service is fully configured
and the server can detach.
Also, rawpart love.
- Introduce randomness into "t_setenv" to avoid freeing environment
variables exactly in the order they have been allocated.
Also call unsetenv(3) twice to make sure it behaves well if the
environment variable doesn't exist.
- "t_getenv" is no longer a known failure after getenv(3) and getenv_r(3)
have been fixed.
1.) Always check the return value of setenv(3) and unsetenv(3).
2.) Test that calling setenv(..., ..., 0) doesn't overwrite environment
variables.
3.) Add a new test which mixes putenv(3) and setenv(3).
plaintext into into an encrypted image and back into plaintext by
doing rump I/O on /dev/cgd. There is one test to check that giving
the same password for both encryption and decryption produces the
same plaintext and another to check that giving a different passwords
does not produce the same plaintext.
This could be fairly easily extended to test all feature of cgd
(hint hint). For example, now cgd.conf is included in cvs, but
the only reason for that is that without further hacking cgdconfig
uses /dev/random quality random to generate the salt for a
pkcsetcetc_kdf2 cgconfig -g, and making an automated test block on
the entropy pool is just not good form. Details are everything.
Yesterday I thought I committed the increased timeout and when the
test was still failing for the autotests n hours later I noticed
I had actually failed to commit it. I did manage to commit something
in the evening, but the autotests were still failing this morning,
so I noticed I increased the timeout of the wrong test. I wonder
what will go wrong this time...
(and p.s.: 10240 is probably slow because it's O(n^2) with a constant
of quite a few)
pooka