Message ID | 20201002201933.250878-1-jonatan.p@gmail.com |
---|---|
State | Superseded |
Headers | show |
Series | scripts/qmp/qom-set: Allow setting integer value | expand |
On 10/2/20 4:19 PM, Jonatan Pålsson wrote: > If the value appears to be an integer, parse it as such. > > This allows the following: > > qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 > > .. where sensor is a tmp105 device, and temperature is an integer > property. > > Signed-off-by: Jonatan Pålsson <jonatan.p@gmail.com> > --- > scripts/qmp/qom-set | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/scripts/qmp/qom-set b/scripts/qmp/qom-set > index 240a78187f..61920680eb 100755 > --- a/scripts/qmp/qom-set > +++ b/scripts/qmp/qom-set > @@ -56,7 +56,10 @@ if len(args) > 1: > path, prop = args[0].rsplit('.', 1) > except: > usage_error("invalid format for path/property/value") > - value = args[1] > + try: > + value = int(args[1]) > + except: > + value = args[1] Please catch the ValueError explicitly. > else: > usage_error("not enough arguments") > > What happens when you don't convert it to int specifically? Does something break? My understanding was that QOM received everything as a string anyway, and does its own parsing.
On Fri, Oct 2, 2020 at 10:29 PM John Snow <jsnow@redhat.com> wrote: > > On 10/2/20 4:19 PM, Jonatan Pålsson wrote: > > If the value appears to be an integer, parse it as such. > > > > This allows the following: > > > > qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 > > > > .. where sensor is a tmp105 device, and temperature is an integer > > property. > > > > Signed-off-by: Jonatan Pålsson <jonatan.p@gmail.com> > > --- > > scripts/qmp/qom-set | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/scripts/qmp/qom-set b/scripts/qmp/qom-set > > index 240a78187f..61920680eb 100755 > > --- a/scripts/qmp/qom-set > > +++ b/scripts/qmp/qom-set > > @@ -56,7 +56,10 @@ if len(args) > 1: > > path, prop = args[0].rsplit('.', 1) > > except: > > usage_error("invalid format for path/property/value") > > - value = args[1] > > + try: > > + value = int(args[1]) > > + except: > > + value = args[1] > > Please catch the ValueError explicitly. Sure, I'll send a v2. > > > else: > > usage_error("not enough arguments") > > > > > > What happens when you don't convert it to int specifically? Does > something break? My understanding was that QOM received everything as a > string anyway, and does its own parsing. With the current implementation, I see this: scripts/qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 Traceback (most recent call last): File "scripts/qmp/qom-set", line 66, in <module> print(srv.command('qom-set', path=path, property=prop, value=value)) File "scripts/qmp/../../python/qemu/qmp.py", line 274, in command raise QMPResponseError(ret) qemu.qmp.QMPResponseError: Invalid parameter type for 'temperature', expected: integer
On 10/2/20 4:36 PM, Jonatan Palsson wrote: > On Fri, Oct 2, 2020 at 10:29 PM John Snow <jsnow@redhat.com> wrote: >> >> On 10/2/20 4:19 PM, Jonatan Pålsson wrote: >>> If the value appears to be an integer, parse it as such. >>> >>> This allows the following: >>> >>> qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 >>> >>> .. where sensor is a tmp105 device, and temperature is an integer >>> property. >>> >>> Signed-off-by: Jonatan Pålsson <jonatan.p@gmail.com> >>> --- >>> scripts/qmp/qom-set | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/scripts/qmp/qom-set b/scripts/qmp/qom-set >>> index 240a78187f..61920680eb 100755 >>> --- a/scripts/qmp/qom-set >>> +++ b/scripts/qmp/qom-set >>> @@ -56,7 +56,10 @@ if len(args) > 1: >>> path, prop = args[0].rsplit('.', 1) >>> except: >>> usage_error("invalid format for path/property/value") >>> - value = args[1] >>> + try: >>> + value = int(args[1]) >>> + except: >>> + value = args[1] >> >> Please catch the ValueError explicitly. > > Sure, I'll send a v2. > >> >>> else: >>> usage_error("not enough arguments") >>> >>> >> >> What happens when you don't convert it to int specifically? Does >> something break? My understanding was that QOM received everything as a >> string anyway, and does its own parsing. > > With the current implementation, I see this: > > scripts/qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 > Traceback (most recent call last): > File "scripts/qmp/qom-set", line 66, in <module> > print(srv.command('qom-set', path=path, property=prop, value=value)) > File "scripts/qmp/../../python/qemu/qmp.py", line 274, in command > raise QMPResponseError(ret) > qemu.qmp.QMPResponseError: Invalid parameter type for 'temperature', > expected: integer > Oh, unfortunate. I hope there aren't any cases where QOM expects a string, but can accept a string where a numerical value is otherwise valid. These are just debugging scripts, so I guess this is probably okay to just change and see if anything explodes. (A more robust solution might actually attempt to query QEMU to get the QOM property types and judiciously apply conversions. A problem for another day?) --js
diff --git a/scripts/qmp/qom-set b/scripts/qmp/qom-set index 240a78187f..61920680eb 100755 --- a/scripts/qmp/qom-set +++ b/scripts/qmp/qom-set @@ -56,7 +56,10 @@ if len(args) > 1: path, prop = args[0].rsplit('.', 1) except: usage_error("invalid format for path/property/value") - value = args[1] + try: + value = int(args[1]) + except: + value = args[1] else: usage_error("not enough arguments")
If the value appears to be an integer, parse it as such. This allows the following: qmp/qom-set -s ~/qmp.sock sensor.temperature 20000 .. where sensor is a tmp105 device, and temperature is an integer property. Signed-off-by: Jonatan Pålsson <jonatan.p@gmail.com> --- scripts/qmp/qom-set | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)