qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-4.2 12/13] iotests: Add peek_file* functions


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH for-4.2 12/13] iotests: Add peek_file* functions
Date: Tue, 30 Jul 2019 14:22:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 7/30/19 12:25 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  tests/qemu-iotests/common.rc | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> index 5502c3da2f..78decfd5d5 100644
> --- a/tests/qemu-iotests/common.rc
> +++ b/tests/qemu-iotests/common.rc
> @@ -53,6 +53,26 @@ poke_file()
>      printf "$3" | dd "of=$1" bs=1 "seek=$2" conv=notrunc &>/dev/null
>  }
>  
> +# peek_file_le 'test.img' 512 2 => 65534
> +peek_file_le()
> +{
> +    # Wrap in echo $() to strip spaces
> +    echo $(od -j"$2" -N"$3" --endian=little -An -vtu"$3" "$1")

Requires coreutils' od, but we can patch that later if it proves to be a
problem on other hosts.

I used to do something similar in nbdkit (prior to qemu-nbd --list
making my life a lot easier; see nbdkit commit b228cb40); but there, I
read a 16-bit value in 2 8-bit chunks and pieced it together myself
rather than relying on --endian:

-    # Protocol is big endian, we want native endian.
-    # xargs trick to trim whitespace from
-    # https://stackoverflow.com/a/12973694
-    eflags_hi=$(od -An -N1     -tx1 eflags.out | xargs)
-    eflags_lo=$(od -An -N1 -j1 -tx1 eflags.out | xargs)
-    eflags=$(( 0x$eflags_hi << 8 | 0x$eflags_lo ))

But as long as we are using --endian, your version nicely handles 1, 2,
4, and 8-byte reads.

> +
> +# peek_file_raw 'test.img' 512 2 => '\xff\xfe'
> +peek_file_raw()
> +{
> +    dd if="$1" bs=1 skip="$2" count="$3" status=none
> +}

Of course, calling $(peek_file_raw ...) is a bad idea, because it might
eat a trailing byte that happened to be a newline; it also doesn't
handle NUL bytes very well.  Is it worth documenting caveats for using
this one?

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]