Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
Il 12/11/2013 10:58, Igor Mammedov ha scritto: extending QemuOpts to parsing ±opts format, seems like good workaround above problem. But I was under impression that general movement was to convert custom formats to canonical format prop=value. I think the general movement is to convert things to QemuOpts. As long as all compound options use QemuOpts, they are consistent and any syntactic sugar will apply to all in the same way. I, for one, can never remember if it is =on, =true, =yes (and interestingly =no works but =yes doesn't). So I welcome a new completely different syntax that doesn't have this problem. :) Paolo
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
Il 12/11/2013 13:45, Andreas Färber ha scritto: Heh. I do not understand movements in the qemu project most of the time :) I thought I could have added compat to PowerPC CPU as others did but I was so wrong :) Hey, I instructed you how to do exactly that, with a const char * argument, but you chose rather to experiment more with QemuOpts. ;) Don't blame us! :-) At least you had a healthy dose of smileys! :) (Me too, apparently). I like Alexey's idea. Paolo
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On Wed, 13 Nov 2013 13:07:26 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/13/2013 12:11 AM, Igor Mammedov wrote:
On Tue, 12 Nov 2013 23:39:27 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 12.11.2013 20:58, Igor Mammedov wrote:
On Tue, 12 Nov 2013 10:49:58 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const
char *params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a
manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work
there.
What particular x86 CPU option cannot be handled the way as PPC's VSX
is
handled two patches below? As I see, even static properties will work
there
fine.
There is legacy code that is kept for CLI compatibility reasons.
Please, look at following features in cpu_x86_parse_featurestr():
xlevel, tsc-freq hv-spinlocks
Ok, I do not know for sure if static properties support setters/getters
(they do not if I remember correct) but what does prevent these x86
properties from being _dynamic_?
nothing, except of:
* it's better to keep CPU device model clean from legacy hacks so that
legacy
silent fixups of invalid values won't be available via other interfaces
except of CLI. That will force users to use correct property names/values
and not break old users that use legacy CLI options.
the rest feature flags on x86 should be handled just fine by your patch,
once x86properties series is applied.
that's why we are talking about parser hook that could be overridden
by target if necessary.
This part confuses me the most. I thought I added the hook and I did not
change other than PPC archs so my patches should have gone quite easily
to upstream but instead I was told (I think I was but I could
misunderstand) that other folks may be unhappy that my stuff does not
support +foo/-foo (which could be added later).
Could you please point me to the x86properties patch(es) which everybody
is waiting for? Thanks!
latest is available at
https://github.com/imammedo/qemu/tree/x86-cpu-properties.v10.1
which basically is a rebase with fixed conflicts of v9
http://comments.gmane.org/gmane.comp.emulators.qemu/84
Wow. This explains a lot. Thanks. Is there any plan to use QemuOpts for all
of this, instead of cpu_x86_parse_featurestr()?
the plan was to keep, +/-/fixups as legacy in target specific code (x86,
sparc) not polluting the rest targets. For not affected targets use only
foo=val notation in CLI/monitor.
So providing a generic parser of cpu_model string for most targets and having
a hook override with custom parser on x86,sparc would be one of simplest
solutions.
--
Alexey
--
Regards,
Igor
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On Tue, 12 Nov 2013 10:49:58 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work there.
What particular x86 CPU option cannot be handled the way as PPC's VSX is
handled two patches below? As I see, even static properties will work there
fine.
There is legacy code that is kept for CLI compatibility reasons.
Please, look at following features in cpu_x86_parse_featurestr():
xlevel, tsc-freq hv-spinlocks
the rest feature flags on x86 should be handled just fine by your patch,
once x86properties series is applied.
that's why we are talking about parser hook that could be overridden
by target if necessary.
PS:
extending QemuOpts to parsing +/-opts format, seems like good workaround
above problem. But I was under impression that general movement was to convert
custom formats to canonical format prop=value.
--
Alexey
--
Regards,
Igor
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On 12.11.2013 20:58, Igor Mammedov wrote:
On Tue, 12 Nov 2013 10:49:58 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work there.
What particular x86 CPU option cannot be handled the way as PPC's VSX is
handled two patches below? As I see, even static properties will work there
fine.
There is legacy code that is kept for CLI compatibility reasons.
Please, look at following features in cpu_x86_parse_featurestr():
xlevel, tsc-freq hv-spinlocks
Ok, I do not know for sure if static properties support setters/getters
(they do not if I remember correct) but what does prevent these x86
properties from being _dynamic_?
the rest feature flags on x86 should be handled just fine by your patch,
once x86properties series is applied.
that's why we are talking about parser hook that could be overridden
by target if necessary.
This part confuses me the most. I thought I added the hook and I did not
change other than PPC archs so my patches should have gone quite easily
to upstream but instead I was told (I think I was but I could
misunderstand) that other folks may be unhappy that my stuff does not
support +foo/-foo (which could be added later).
Could you please point me to the x86properties patch(es) which everybody
is waiting for? Thanks!
PS:
extending QemuOpts to parsing +/-opts format, seems like good workaround
above problem. But I was under impression that general movement was to convert
custom formats to canonical format prop=value.
Heh. I do not understand movements in the qemu project most of the time
:) I thought I could have added compat to PowerPC CPU as others did
but I was so wrong :)
--
With best regards
Alexey Kardashevskiy -- icq: 52150396
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
Am 12.11.2013 13:39, schrieb Alexey Kardashevskiy: On 12.11.2013 20:58, Igor Mammedov wrote: PS: extending QemuOpts to parsing +/-opts format, seems like good workaround above problem. But I was under impression that general movement was to convert custom formats to canonical format prop=value. Heh. I do not understand movements in the qemu project most of the time :) I thought I could have added compat to PowerPC CPU as others did but I was so wrong :) Hey, I instructed you how to do exactly that, with a const char * argument, but you chose rather to experiment more with QemuOpts. ;) Don't blame us! :-) Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On Tue, 12 Nov 2013 23:39:27 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 12.11.2013 20:58, Igor Mammedov wrote:
On Tue, 12 Nov 2013 10:49:58 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const
char *params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work
there.
What particular x86 CPU option cannot be handled the way as PPC's VSX is
handled two patches below? As I see, even static properties will work there
fine.
There is legacy code that is kept for CLI compatibility reasons.
Please, look at following features in cpu_x86_parse_featurestr():
xlevel, tsc-freq hv-spinlocks
Ok, I do not know for sure if static properties support setters/getters
(they do not if I remember correct) but what does prevent these x86
properties from being _dynamic_?
nothing, except of:
* it's better to keep CPU device model clean from legacy hacks so that legacy
silent fixups of invalid values won't be available via other interfaces
except of CLI. That will force users to use correct property names/values
and not break old users that use legacy CLI options.
the rest feature flags on x86 should be handled just fine by your patch,
once x86properties series is applied.
that's why we are talking about parser hook that could be overridden
by target if necessary.
This part confuses me the most. I thought I added the hook and I did not
change other than PPC archs so my patches should have gone quite easily
to upstream but instead I was told (I think I was but I could
misunderstand) that other folks may be unhappy that my stuff does not
support +foo/-foo (which could be added later).
Could you please point me to the x86properties patch(es) which everybody
is waiting for? Thanks!
latest is available at
https://github.com/imammedo/qemu/tree/x86-cpu-properties.v10.1
which basically is a rebase with fixed conflicts of v9
http://comments.gmane.org/gmane.comp.emulators.qemu/84
PS:
extending QemuOpts to parsing +/-opts format, seems like good workaround
above problem. But I was under impression that general movement was to
convert
custom formats to canonical format prop=value.
Heh. I do not understand movements in the qemu project most of the time
:) I thought I could have added compat to PowerPC CPU as others did
but I was so wrong :)
--
With best regards
Alexey Kardashevskiy -- icq: 52150396
--
Regards,
Igor
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On 11/12/2013 11:45 PM, Andreas Färber wrote: Am 12.11.2013 13:39, schrieb Alexey Kardashevskiy: On 12.11.2013 20:58, Igor Mammedov wrote: PS: extending QemuOpts to parsing +/-opts format, seems like good workaround above problem. But I was under impression that general movement was to convert custom formats to canonical format prop=value. Heh. I do not understand movements in the qemu project most of the time :) I thought I could have added compat to PowerPC CPU as others did but I was so wrong :) Hey, I instructed you how to do exactly that, with a const char * argument, but you chose rather to experiment more with QemuOpts. ;) Don't blame us! :-) So instead of reusing QemuOpts infrastructure, you suggest to re-implement the parser one more time, don't you? I still cannot believe it. -- Alexey
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On 11/13/2013 12:11 AM, Igor Mammedov wrote:
On Tue, 12 Nov 2013 23:39:27 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 12.11.2013 20:58, Igor Mammedov wrote:
On Tue, 12 Nov 2013 10:49:58 +1100
Alexey Kardashevskiy a...@ozlabs.ru wrote:
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const
char *params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work
there.
What particular x86 CPU option cannot be handled the way as PPC's VSX is
handled two patches below? As I see, even static properties will work there
fine.
There is legacy code that is kept for CLI compatibility reasons.
Please, look at following features in cpu_x86_parse_featurestr():
xlevel, tsc-freq hv-spinlocks
Ok, I do not know for sure if static properties support setters/getters
(they do not if I remember correct) but what does prevent these x86
properties from being _dynamic_?
nothing, except of:
* it's better to keep CPU device model clean from legacy hacks so that legacy
silent fixups of invalid values won't be available via other interfaces
except of CLI. That will force users to use correct property names/values
and not break old users that use legacy CLI options.
the rest feature flags on x86 should be handled just fine by your patch,
once x86properties series is applied.
that's why we are talking about parser hook that could be overridden
by target if necessary.
This part confuses me the most. I thought I added the hook and I did not
change other than PPC archs so my patches should have gone quite easily
to upstream but instead I was told (I think I was but I could
misunderstand) that other folks may be unhappy that my stuff does not
support +foo/-foo (which could be added later).
Could you please point me to the x86properties patch(es) which everybody
is waiting for? Thanks!
latest is available at
https://github.com/imammedo/qemu/tree/x86-cpu-properties.v10.1
which basically is a rebase with fixed conflicts of v9
http://comments.gmane.org/gmane.comp.emulators.qemu/84
Wow. This explains a lot. Thanks. Is there any plan to use QemuOpts for all
of this, instead of cpu_x86_parse_featurestr()?
--
Alexey
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On 2013-11-11 13:41, Andreas Färber wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
hostfwd starts with : in the simplest case - or what pattern do you
have in mind?
Jan
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
Regards,
Andreas
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
Am 11.11.2013 13:52, schrieb Jan Kiszka:
On 2013-11-11 13:41, Andreas Färber wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
hostfwd starts with : in the simplest case - or what pattern do you
have in mind?
Ah right, I had :8022-:22 or so in mind and mixed up optional host name
with optional source port.
Basically I'm checking for anything which is using the generic QemuOpts
parsing and where a literal + or - may lead to unexpected parsing
changes with this patch. Without having looked up more context for this
hunk, it should not affect foo=-bar but only where foo= is optional,
such as type names for driver= starting with either character (not aware
of such types though).
Andreas
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work there.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
Regards,
Igor
Re: [Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
On 11/12/2013 01:25 AM, Igor Mammedov wrote:
On Mon, 11 Nov 2013 13:41:05 +0100
Andreas Färber afaer...@suse.de wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
This looks like an interesting idea! However this is much too big a
change to just CC ppc folks on...
Jan, I wonder if this might break slirp's hostfwd option?
Not sure what other options potentially starting with '-' might be
affected. Test cases would be a helpful way of demonstrating that this
change does not have undesired side effects.
on x86 there is several value fixups for compatibility reason and a manual
value parsing in cpu_x86_parse_featurestr(), so above won't just work there.
What particular x86 CPU option cannot be handled the way as PPC's VSX is
handled two patches below? As I see, even static properties will work there
fine.
--
Alexey
[Qemu-devel] [PATCH v3 4/6] qemu-option: support +foo/-foo command line agruments
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
util/qemu-option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index efcb5dc..6c8667c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -890,6 +890,12 @@ static int opts_do_parse(QemuOpts *opts, const char
*params,
if (strncmp(option, no, 2) == 0) {
memmove(option, option+2, strlen(option+2)+1);
pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, -, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), off);
+} else if (strncmp(option, +, 1) == 0) {
+memmove(option, option+1, strlen(option+1)+1);
+pstrcpy(value, sizeof(value), on);
} else {
pstrcpy(value, sizeof(value), on);
}
--
1.8.4.rc4
