From: Karel Zak <kzak@redhat.com>
To: Sami Kerola <kerolasa@iki.fi>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH 3/8] libuuid: add uuid_generate_file() function
Date: Fri, 16 Oct 2015 11:18:55 +0200 [thread overview]
Message-ID: <20151016091855.GA2990@ws.net.home> (raw)
In-Reply-To: <1444735754-18976-4-git-send-email-kerolasa@iki.fi>
On Tue, Oct 13, 2015 at 12:29:09PM +0100, Sami Kerola wrote:
> The uuid_generate_file() allows generating UUID using input file, and thus
> leading to stable output. Purpose of this function is to have a facility
> that allows tests to be wrote.
Well, if you want to generate non-random stuff then it seems enough
to modify __uuid_generate_random() and __uuid_generate_time()
to return non-random stuff on -DLIBUUID_ENABLE_TEST.
The problem is that things like get_clock(), pack, unpack, parse and
unparse functions will be still untested.
What about to support random UUIDs in our tests and modify
the __uuid_generate functions to copy unpacked raw result to any
file? Something like:
int __uuid_generate_time(uuid_t out, int *num)
{
... generate struct uu as usually ...
#ifdef LIBUUID_ENABLE_TEST
ts_path = genenv("LIBUUID_TEST_PATH");
if (ts_path)
write_raw_uuid(uu, ts_path);
#endif
return ret;
}
where write_uraw_uuid() is function to write struct uuid to the
<ts_path>/<pid>.
Then we can write
test_uuid --random|--time <file>
this program
1/ ask libuuid for a new UUID
2/ unparse and unpack to get struct uuid
3/ write struct uuid to the <file> by write_uraw_uuid()
and in the shell script we can by diff -u compare $LIBUUID_TEST_PATH/<pid>
with <file>.
The <pid> is also possible to use to check if UUID has been really
generated by uuidd. (It would be nice to have two sub-tests, one with
uuidd and one without uuid.)
Note that uuid_unpack() is not exported by library API, so you have to
link libuuid/src/unpack.c directly to the test_uuid.c.
(It would be also possible to analyze struct uuid from
$LIBUUID_TEST_PATH to make sure that for example get_node_id() works
as expected, etc... but this is not urgent.)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2015-10-16 9:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 11:29 [PATCH 0/8] [pull] various changes, uuid tests, ctrlaltdel improvements and so on Sami Kerola
2015-10-13 11:29 ` [PATCH 1/8] last: display input file in usage() according to command name Sami Kerola
2015-10-13 11:29 ` [PATCH 2/8] nologin: require /etc/nologin.txt to be file Sami Kerola
2015-10-13 11:29 ` [PATCH 3/8] libuuid: add uuid_generate_file() function Sami Kerola
2015-10-16 9:18 ` Karel Zak [this message]
2015-10-13 11:29 ` [PATCH 4/8] tests: add uuidgen check Sami Kerola
2015-10-13 11:29 ` [PATCH 5/8] tests: add uuidd check Sami Kerola
2015-10-13 11:29 ` [PATCH 6/8] ctrlaltdel: improve error messaging Sami Kerola
2015-10-13 11:29 ` [PATCH 7/8] docs: update ctrlaltdel.8 man page Sami Kerola
2015-10-13 11:29 ` [PATCH 8/8] ctrlaltdel: display setting when ran without arguments Sami Kerola
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=20151016091855.GA2990@ws.net.home \
--to=kzak@redhat.com \
--cc=kerolasa@iki.fi \
--cc=util-linux@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