On Tue, 2020-06-16 at 15:17 +0200, Max Reitz wrote: > Right now, _filter_img_create just filters out everything that looks > format-dependent, and applies some filename filters. That means that we > have to add another filter line every time some format gets a new > creation option. This can be avoided by instead discarding everything > and just keeping what we know is format-independent (format, size, > backing file, encryption information[1], preallocation) or just > interesting to have in the reference output (external data file path). > > Furthermore, we probably want to sort these options. Format drivers are > not required to define them in any specific order, so the output is > effectively random (although this has never bothered us until now). We > need a specific order for our reference outputs, though. Unfortunately, > just using a plain "sort" would change a lot of existing reference > outputs, so we have to pre-filter the option keys to keep our existing > order (fmt, size, backing*, data, encryption info, preallocation). > > [1] Actually, the only thing that is really important is whether > encryption is enabled or not. A patch by Maxim thus removes all > other "encrypt.*" options from the output: > https://lists.nongnu.org/archive/html/qemu-block/2020-06/msg00339.html > But that patch needs to come later so we can get away with changing > as few reference outputs in this patch here as possible. > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > tests/qemu-iotests/112.out | 2 +- > tests/qemu-iotests/153 | 9 ++- > tests/qemu-iotests/common.filter | 100 +++++++++++++++++++++++-------- > 3 files changed, 81 insertions(+), 30 deletions(-) > > diff --git a/tests/qemu-iotests/112.out b/tests/qemu-iotests/112.out > index ae0318cabe..182655dbf6 100644 > --- a/tests/qemu-iotests/112.out > +++ b/tests/qemu-iotests/112.out > @@ -5,7 +5,7 @@ QA output created by 112 > qemu-img: TEST_DIR/t.IMGFMT: Refcount width must be a power of two and may > not exceed 64 bits > Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 > qemu-img: TEST_DIR/t.IMGFMT: Refcount width must be a power of two and may > not exceed 64 bits > -Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 refcount_bits=-1 > +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 > qemu-img: TEST_DIR/t.IMGFMT: Refcount width must be a power of two and may > not exceed 64 bits > Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 > qemu-img: TEST_DIR/t.IMGFMT: Refcount width must be a power of two and may > not exceed 64 bits > diff --git a/tests/qemu-iotests/153 b/tests/qemu-iotests/153 > index cf961d3609..11e3d28841 100755 > --- a/tests/qemu-iotests/153 > +++ b/tests/qemu-iotests/153 > @@ -167,11 +167,10 @@ done > > echo > echo "== Creating ${TEST_IMG}.[abc] ==" | _filter_testdir > -( > - $QEMU_IMG create -f qcow2 "${TEST_IMG}.a" -b "${TEST_IMG}" > - $QEMU_IMG create -f qcow2 "${TEST_IMG}.b" -b "${TEST_IMG}" > - $QEMU_IMG create -f qcow2 "${TEST_IMG}.c" -b "${TEST_IMG}.b" > -) | _filter_img_create > +$QEMU_IMG create -f qcow2 "${TEST_IMG}.a" -b "${TEST_IMG}" | > _filter_img_create > +$QEMU_IMG create -f qcow2 "${TEST_IMG}.b" -b "${TEST_IMG}" | > _filter_img_create > +$QEMU_IMG create -f qcow2 "${TEST_IMG}.c" -b "${TEST_IMG}.b" \ > + | _filter_img_create > > echo > echo "== Two devices sharing the same file in backing chain =="
I guess this is done because now the filter expectes only a single qemu-img output. IMHO this is better anyway. > diff --git a/tests/qemu-iotests/common.filter > b/tests/qemu-iotests/common.filter > index 03e4f71808..f104ad7a9b 100644 > --- a/tests/qemu-iotests/common.filter > +++ b/tests/qemu-iotests/common.filter > @@ -122,38 +122,90 @@ _filter_actual_image_size() > # replace driver-specific options in the "Formatting..." line > _filter_img_create() > { > - data_file_filter=() > - if data_file=$(_get_data_file "$TEST_IMG"); then > - data_file_filter=(-e "s# data_file=$data_file##") > + # Keep QMP output unchanged > + qmp_pre='' > + qmp_post='' > + to_filter='' > + > + while read -r line; do > + if echo "$line" | grep -q '^{.*}$'; then > + if [ -z "$to_filter" ]; then > + # Use $'\n' so the newline is not dropped on variable > + # expansion > + qmp_pre="$qmp_pre$line"$'\n' > + else > + qmp_post="$qmp_post$line"$'\n' > + fi > + else > + to_filter="$to_filter$line"$'\n' > + fi > + done The above code basically assumes that qmp output starts with '{' and ends with '}' which I guess is fair, and then it assumes that we can have set of qmp commands prior to qemu-img line and another set of qmp commands after it. To me it feels like we should have another filter for that, since qemu-img itself doesn't use qmp. Which test needs it? > + > + readarray -td '' formatting_line < \ > + <(echo "$to_filter" | sed -e 's/, fmt=/\x0/') OK, took me a while to understand what this does, but looks OK. > + > + filename_part=${formatting_line[0]} > + if [ -n "${formatting_line[1]}" ]; then > + options="fmt=${formatting_line[1]}" > + else > + options='' > fi > OK. > > - $SED "${data_file_filter[@]}" \ > + # Set grep_data_file to '\|data_file' to keep it; make it empty > + # to drop it. > + # We want to drop it if it is part of the global $IMGOPTS, and we > + # want to keep it otherwise (if the test specifically wants to > + # test data files). > + grep_data_file='\|data_file' > + if _get_data_file "$TEST_IMG" > /dev/null; then > + grep_data_file='' > + fi > + > + filename_filters=( > -e "s#$REMOTE_TEST_DIR#TEST_DIR#g" \ > -e "s#$IMGPROTO:$TEST_DIR#TEST_DIR#g" \ > -e "s#$TEST_DIR#TEST_DIR#g" \ > -e "s#$SOCK_DIR#SOCK_DIR#g" \ > -e "s#$IMGFMT#IMGFMT#g" \ > -e 's#nbd:127.0.0.1:[0-9]\\+#TEST_DIR/t.IMGFMT#g' \ > - -e 's#nbd+unix:///\??socket=SOCK_DIR/nbd#TEST_DIR/t.IMGFMT#g' \ > - -e "s# encryption=off##g" \ > - -e "s# cluster_size=[0-9]\\+##g" \ > - -e "s# table_size=[0-9]\\+##g" \ > - -e "s# compat=[^ ]*##g" \ > - -e "s# compat6=\\(on\\|off\\)##g" \ > - -e "s# static=\\(on\\|off\\)##g" \ > - -e "s# zeroed_grain=\\(on\\|off\\)##g" \ > - -e "s# subformat=[^ ]*##g" \ > - -e "s# adapter_type=[^ ]*##g" \ > - -e "s# hwversion=[^ ]*##g" \ > - -e "s# lazy_refcounts=\\(on\\|off\\)##g" \ > - -e "s# block_size=[0-9]\\+##g" \ > - -e "s# block_state_zero=\\(on\\|off\\)##g" \ > - -e "s# log_size=[0-9]\\+##g" \ > - -e "s# refcount_bits=[0-9]\\+##g" \ > - -e "s# key-secret=[a-zA-Z0-9]\\+##g" \ > - -e "s# iter-time=[0-9]\\+##g" \ > - -e "s# force_size=\\(on\\|off\\)##g" \ > - -e "s# compression_type=[a-zA-Z0-9]\\+##g" > + -e 's#nbd+unix:///\??socket=SOCK_DIR/nbd#TEST_DIR/t.IMGFMT#g' > + ) > + > + filename_part=$(echo "$filename_part" | $SED "${filename_filters[@]}") Looks good as well. > + > + # Break the option line before each option (preserving pre-existing > + # line breaks by replacing them by \0 and restoring them at the end), > + # then filter out the options we want to keep and sort them according > + # to some order that all block drivers used at the time of writing > + # this function. > + options=$( > + echo "$options" \ > + | tr '\n' '\0' \ > + | sed -e 's/\x0$//' -e 's/ \([a-z0-9_.-]*\)=/\n\1=/g' \ You sometimes use $SED and sometimes sed. Is this intentional? > + | grep -ae > "^\(fmt\\|size\\|backing\\|preallocation\\|encrypt$grep_data_file\\)" \ > + | $SED "${filename_filters[@]}" \ > + -e 's/^\(fmt\)/0-\1/' \ > + -e 's/^\(size\)/1-\1/' \ > + -e 's/^\(backing\)/2-\1/' \ > + -e 's/^\(data_file\)/3-\1/' \ > + -e 's/^\(encryption\)/4-\1/' \ > + -e 's/^\(encrypt\.format\)/5-\1/' \ > + -e 's/^\(encrypt\.key-secret\)/6-\1/' \ > + -e 's/^\(encrypt\.iter-time\)/7-\1/' \ > + -e 's/^\(preallocation\)/8-\1/' \ All right, I understand this now, but do we have to do this? Maybe it is better to just update the outputs once to avoid keeping the custom sort order? > + | sort \ > + | $SED -e 's/^[0-9]-//' \ > + | tr '\n\0' ' \n' \ > + | $SED -e 's/^ *$//' -e 's/ *$//' > + ) For the above bash pipeline overall: It was hard to decipher :-), but I must admit I learned something from it. > + > + echo -n "$qmp_pre" > + if [ -n "$options" ]; then > + echo "$filename_part, $options" > + elif [ -n "$filename_part" ]; then > + echo "$filename_part" > + fi > + echo -n "$qmp_post" > } > > _filter_img_create_size() Overall I like the idea of this patch. Best regards, Maxim Levitsky