On 12/29/2011 11:22 AM, Avi Kivity wrote:
On 12/29/2011 07:14 PM, Anthony Liguori wrote:
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to write qtest tests.
Overtime, that libOS will become increasingly complex up until the
point where it approaches something that feels like an actual OS.
Effort spent developing libOS is a cost to building test cases.
By using Linux and a minimal userspace as our libOS, we can avoid
spending a lot of time building a sophisticated libOS. If we need
advanced libOS features, we just use qemu-test. If it's just a matter
of poking some registers on a device along, we just use qtest.
Would there be device-level tests in qemu-test?
What is a "device-level" test?
A test that tests just one device (or a patch to a single device's
device emulation).
Take a look at:
http://git.qemu.org/?p=qemu-test.git;a=blob;f=scripts/bin/fingerprint;h=2d4202a826917b16856a2acb4617f623fdc4c0d3;hb=HEAD
It's reading BAR0 from any virtio devices to determine the guest
features exposed. Yes, it's written in sh :-)
It would be trivial once libos exists. And we need libos so we can
-ENOTEST device patches, yes?
Or qemu-test. I'd be happy with a test like the virtio-serial test that I
posted for qemu-test.
I expect we'll have a solid libos for x86 but I doubt we'll ever have a solid
libos for other targets.
Regards,
Anthony Liguori
It uses the BAR mappings that sysfs exposes.
