[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v3 4/4] qemu-iotests: Test creating
Re: [Qemu-block] [Qemu-devel] [PATCH v3 4/4] qemu-iotests: Test creating floppy drives
Wed, 19 Oct 2016 09:47:02 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
On 10/19/2016 03:37 AM, Kevin Wolf wrote:
Am 18.10.2016 um 21:53 hat Eric Blake geschrieben:
On 10/18/2016 02:45 PM, John Snow wrote:
On 10/18/2016 06:22 AM, Kevin Wolf wrote:
This tests the different supported methods to create floppy drives and
how they interact.
+ echo Testing: "$@" | _filter_testdir
+ # QEMU_OPTIONS contains -nodefaults, we don't want that here
+ # defaults are part of what should be checked here
+ echo "info qtree" |
+ QEMU_OPTIONS="" do_run_qemu "$@" | _filter_win32 |
+ grep -zo '[[:cntrl:]]\( *\)dev: isa-fdc.*\([[:cntrl:]]\1
This grep invocation doesn't appear to actually terminate with the '-z'
option here. Not sure why, I haven't looked into the bash framework
much, hopefully it's not too hard for you to reproduce and correct.
No, obviously I can't reproduce, otherwise I wouldn't have written the
test case like this. It passes just fine for me on RHEL 7.
Wasn't sure if it was something that popped up more recently or not.
Obviously it worked at some point.
I'm on Fedora 24, using bash 4.3.42-7.fc24 and grep 2.25-1.fc24.
Just to clarify, it's grep that doesn't terminate, or qemu? Also, what
do you mean by the "bash framework"?
It seems like it's the grep invocation; I don't see any QEMU processes
in `ps`, the only thing I can find is the grep invocation. (Why would
grep hang if qemu has exited?)
By the 'bash framework' I meant the shell related infrastructure for
iotests. I'm more familiar with the python parts.
Is 'grep -z' even portable to BSD, or is it just a GNU extension? Would
it be better to run the output through tr to convert things to a saner
subset of characters before then grepping a text file?
Is qemu-iotests even supposed to run on BSD? All our test cases specify
"_supported_os Linux". (And I don't think this means Linux kernel with
BSD userland :-))
Anyway, the tr thing you mean would be translating all newlines into
something else (which is hopefully otherwise unused), then grep, then
What this line is supposed to do (if it wasn't obvious) is extracting
the full information for a single device from 'info qtree'. I don't
really mind how it's done, but multiline operation seems to be something
that isn't trivial with most tools... I think I've done multiline sed
before, so maybe that would be another option.