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? > It uses the BAR mappings that sysfs exposes. -- error compiling committee.c: too many arguments to function
