<feed xmlns='http://www.w3.org/2005/Atom'>
<title>passt/test/lib, branch 2022_07_20.9af2e5d</title>
<subtitle>Plug A Simple Socket Transport</subtitle>
<link rel='alternate' type='text/html' href='https://passt.top/passt/'/>
<entry>
<title>tests: Explicitly list test files in test/run, remove "onlyfor" support</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:06+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=a832a44e67e77dd1a9ec57e9c054feddb0355cfc'/>
<id>a832a44e67e77dd1a9ec57e9c054feddb0355cfc</id>
<content type='text'>
Currently test/run uses wildcards to run all of the tests in a directory.
However, that wildcard list is filtered down by the "onlyfor" directives
in the test files... usually to a single file.

Therefore, just explicitly list the files we *really* want to run for this
test mode.  This makes it easier to see at the top level what tests will
be executed, and to change that list temporarily while debugging specific
failures.

This means the "onlyfor" directive no longer has any purpose, and we can
remove it.  "onlyfor" was also the only used of the $MODE variable, so we
can remove that too.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently test/run uses wildcards to run all of the tests in a directory.
However, that wildcard list is filtered down by the "onlyfor" directives
in the test files... usually to a single file.

Therefore, just explicitly list the files we *really* want to run for this
test mode.  This makes it easier to see at the top level what tests will
be executed, and to change that list temporarily while debugging specific
failures.

This means the "onlyfor" directive no longer has any purpose, and we can
remove it.  "onlyfor" was also the only used of the $MODE variable, so we
can remove that too.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Don't automatically traverse directories of test files</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:05+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=544f790bf837ebe7d7e25fa59a5790e5dbb412a1'/>
<id>544f790bf837ebe7d7e25fa59a5790e5dbb412a1</id>
<content type='text'>
The top level listing control of which tests to run is in test/run, however
it uses the test() function which runs an entire directory of test files,
filtered by some criteria.  This makes it awkward to narrow down to a
subset of tests when debugging a specific failure.

To make this easier, have test() take an explicit list of test files to
run, and have the caller in test/run handle the directory traversal.  The
construct we use for this is pretty awkward to handle the fact that we're
in the source tree root directory rather than test/ at this point in
test/run.  Later cleanups will improve that.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The top level listing control of which tests to run is in test/run, however
it uses the test() function which runs an entire directory of test files,
filtered by some criteria.  This makes it awkward to narrow down to a
subset of tests when debugging a specific failure.

To make this easier, have test() take an explicit list of test files to
run, and have the caller in test/run handle the directory traversal.  The
construct we use for this is pretty awkward to handle the fact that we're
in the source tree root directory rather than test/ at this point in
test/run.  Later cleanups will improve that.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Remove not-very-useful "req" directive</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=5d7688d26f616831731a550f4a422f67aed9d21f'/>
<id>5d7688d26f616831731a550f4a422f67aed9d21f</id>
<content type='text'>
The test scripts support a "req" directive which requires one test script
to be run before another.  It's implemented by doing a topological sort
based on these directives in the runner scripts, which is about as awkward
as you'd expect in Bourne shell.

It turns out we only use this functionality in one place - to make the
"make install" test run after the plain "make" test.  We also already have
a simpler way of making sure tests run in a specific order: just put them
into the same test script file.

So, remove support for the "req" directive and just fold the build/all and
build/install test scripts together.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The test scripts support a "req" directive which requires one test script
to be run before another.  It's implemented by doing a topological sort
based on these directives in the runner scripts, which is about as awkward
as you'd expect in Bourne shell.

It turns out we only use this functionality in one place - to make the
"make install" test run after the plain "make" test.  We also already have
a simpler way of making sure tests run in a specific order: just put them
into the same test script file.

So, remove support for the "req" directive and just fold the build/all and
build/install test scripts together.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Remove unused set_mode() function</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:03+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=eb2e86dec0dea0c63c548944246ed1c2df0ffddb'/>
<id>eb2e86dec0dea0c63c548944246ed1c2df0ffddb</id>
<content type='text'>
This utility function is never called.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This utility function is never called.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Move mbuto download and execution to asset build</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:00+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=2297637251d98f639a38f2af23a9913eab01200d'/>
<id>2297637251d98f639a38f2af23a9913eab01200d</id>
<content type='text'>
Move the download of mbuto and using it to create a sample initramfs to
the asset build makefile, rather than embedding it in the test scripts
themselves.

The two_guests tests used to use two separate copies of the mbuto
image.  As an initramfs the mbuto image is strictly readonly though,
so that's not necessary.  So, also use the same image for both guests.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move the download of mbuto and using it to create a sample initramfs to
the asset build makefile, rather than embedding it in the test scripts
themselves.

The two_guests tests used to use two separate copies of the mbuto
image.  As an initramfs the mbuto image is strictly readonly though,
so that's not necessary.  So, also use the same image for both guests.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Introduce makefile for building test assets</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:28:59+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=db551e5de02a46517f40f2320b85ae65a877fe6b'/>
<id>db551e5de02a46517f40f2320b85ae65a877fe6b</id>
<content type='text'>
A number of passt/pasta testcases have initial steps which are just about
building images or other assets we need for the test proper.  Repeating
these for each test run can be quite costly.

This patch makes a start on moving this sort of test asset building to
a separate phase before running the tests proper.  For now just add a
Makefile to handle the asset building (although it doesn't build
anything yet), and make the path where we'll be building the assets
available to the tests.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A number of passt/pasta testcases have initial steps which are just about
building images or other assets we need for the test proper.  Repeating
these for each test run can be quite costly.

This patch makes a start on moving this sort of test asset building to
a separate phase before running the tests proper.  For now just add a
Makefile to handle the asset building (although it doesn't build
anything yet), and make the path where we'll be building the assets
available to the tests.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Invoke specific qemu-system-* binaries</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:28:58+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=7bcc5930a66ed8d6ba692a2463547d17390531e7'/>
<id>7bcc5930a66ed8d6ba692a2463547d17390531e7</id>
<content type='text'>
A lot of tests and examples invoke qemu with the command "kvm".  However,
as far as I can tell, "kvm" being aliased to the appropriate qemu system
binary is Debian specific.  The binary names from qemu upstream -
qemu-system-$ARCH - also aren't universal, but they are more common (they
should be good for both Debian and Fedora at least).

In order to still get KVM acceleration when available, we use the option
"-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that
order

A number of the places we invoked "kvm" are expecting specifically an x86
guest, and so it's also safer to explicitly invoke qemu-system-x86_64.

Some others appear to be independent of the target arch (just wanting the
same arch as the host to allow KVM acceleration).  Although I suspect there
may be more subtle x86 specific options in the qemu command lines, attempt
to preserve arch independence by using $(uname -m).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A lot of tests and examples invoke qemu with the command "kvm".  However,
as far as I can tell, "kvm" being aliased to the appropriate qemu system
binary is Debian specific.  The binary names from qemu upstream -
qemu-system-$ARCH - also aren't universal, but they are more common (they
should be good for both Debian and Fedora at least).

In order to still get KVM acceleration when available, we use the option
"-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that
order

A number of the places we invoked "kvm" are expecting specifically an x86
guest, and so it's also safer to explicitly invoke qemu-system-x86_64.

Some others appear to be independent of the target arch (just wanting the
same arch as the host to allow KVM acceleration).  Although I suspect there
may be more subtle x86 specific options in the qemu command lines, attempt
to preserve arch independence by using $(uname -m).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test: Add external mbuto profile, drop udhcpc, and switch to it</title>
<updated>2022-07-06T06:09:26+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-06-23T12:34:54+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=20c418f1f911f8a6c75b3d83fdab52ee4840640d'/>
<id>20c418f1f911f8a6c75b3d83fdab52ee4840640d</id>
<content type='text'>
This depends on a future change in mbuto to accept external profile
files. Add a file defining what we need for tests and demos, dropping
udhcpc and script as they're not needed anymore, and switch to it.

Suggested-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This depends on a future change in mbuto to accept external profile
files. Add a file defining what we need for tests and demos, dropping
udhcpc and script as they're not needed anymore, and switch to it.

Suggested-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Use dhclient instead of udhcpc</title>
<updated>2022-06-15T07:38:10+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-10T02:32:44+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=e48373382f7c84175a0f61890e8f0164cdd2d329'/>
<id>e48373382f7c84175a0f61890e8f0164cdd2d329</id>
<content type='text'>
For some reason, the passt/pasta tests and examples use dhclient for
DHCPv6, but in most cases use udhcpc for DHCPv4.  Change it to use dhclient
for both DHCPv4 and DHCPv6.  This means one less tool we need for testing,
plus dhclient is easily available on Fedora whereas udhcpc is not.

Note that the passt tests still rely on udhcpc indirectly because mbuto
wants to put it into the guest images it generates.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For some reason, the passt/pasta tests and examples use dhclient for
DHCPv6, but in most cases use udhcpc for DHCPv4.  Change it to use dhclient
for both DHCPv4 and DHCPv6.  This means one less tool we need for testing,
plus dhclient is easily available on Fedora whereas udhcpc is not.

Note that the passt tests still rely on udhcpc indirectly because mbuto
wants to put it into the guest images it generates.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Tweak dhclient arguments for readability</title>
<updated>2022-06-15T07:38:10+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-10T02:32:43+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=ca0c33ae5b8a68806dd1c766e2f58ce24867f334'/>
<id>ca0c33ae5b8a68806dd1c766e2f58ce24867f334</id>
<content type='text'>
A number of tests and examples use dhclient in both IPv4 and IPv6 modes.
We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4.  Add
an explicit "-4" argument to make it more clear and explicit.

In addition, when dhclient is run from within pasta it usually won't be
"real" root, and so will not have access to write the default global pid
file.  This results in a mostly harmless but irritating error:
    Can't create /var/run/dhclient.pid: Permission denied
We can avoid that by using the --no-pid flag to dhclient.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A number of tests and examples use dhclient in both IPv4 and IPv6 modes.
We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4.  Add
an explicit "-4" argument to make it more clear and explicit.

In addition, when dhclient is run from within pasta it usually won't be
"real" root, and so will not have access to write the default global pid
file.  This results in a mostly harmless but irritating error:
    Can't create /var/run/dhclient.pid: Permission denied
We can avoid that by using the --no-pid flag to dhclient.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
