From: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [Qemu-devel] Re: Storing command line options in images
Date: Fri, 10 Aug 2007 15:11:18 -0500 [thread overview]
Message-ID: <46BCC666.6050406@codemonkey.ws> (raw)
In-Reply-To: <46BCBF73.5060406-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>>> This is a big effort but a config file is the right long term
>>>> solution.
>>>>
>>>>
>>>
>>> For which use case? management-full or management-less?
>>>
>>
>> Both. A config file will be useful not just for expressing the
>> functionality we have today, but also for describing the guest's
>> environment in greater detail. For instance, if you want to support
>> a bunch of different kinds of embedded systems, it would be very nice
>> if the machine description was a config file instead of hard coded
>> such that it was easy to tweak what hardware was present for the
>> particular embedded system.
>>
>
> Maybe I'm dense today. Which use case is this?
If you're using QEMU to simulate an embedded platform (ARM or PPC based
for instance). There is a huge amount of variety in embedded platforms
so having to hard code the PC description as a machine type in QEMU is
kind of annoying.
>>> A managed system will want to supply arguments out of a central
>>> database. For a management-less use case, the config file is a hassle.
>>>
>>
>> As long as all options are still settable via command line (or
>> stdio), then it's not at all a hassle.
>>
>
> Yes. But if you don't plan to use it, why implement it?
Well, I do plan to use it. I'm simply saying that you don't have to use
it if you don't want to.
There are a lot of knobs in QEMU and most of them have somewhat
arbitrary defaults. For instance, when I setup a machine, I don't want
to use user networking by default, I want to use tap. A global
configuration file would be terribly useful for this sort of thing.
> My feeling is that config files are outdated. When used with a gui,
> you end up writing silly parsers and stuff and still wrecking things
> horribly when the the gui writer's expectations don't match reality.
> When used without a gui, they increase the amount of details one has
> to remember (where's that config file? I renamed my image, did I
> remember to update the config file?). They also make upgrading more
> difficult.
There's only so much that can be expressed on a command line. There are
actually limits to the command line size on a lot of platforms. I don't
see why reading options from a file is so much worse than reading them
from the command line.
Regards,
Anthony Liguori
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Date: Fri, 10 Aug 2007 15:11:18 -0500 [thread overview]
Message-ID: <46BCC666.6050406@codemonkey.ws> (raw)
In-Reply-To: <46BCBF73.5060406@qumranet.com>
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>>> This is a big effort but a config file is the right long term
>>>> solution.
>>>>
>>>>
>>>
>>> For which use case? management-full or management-less?
>>>
>>
>> Both. A config file will be useful not just for expressing the
>> functionality we have today, but also for describing the guest's
>> environment in greater detail. For instance, if you want to support
>> a bunch of different kinds of embedded systems, it would be very nice
>> if the machine description was a config file instead of hard coded
>> such that it was easy to tweak what hardware was present for the
>> particular embedded system.
>>
>
> Maybe I'm dense today. Which use case is this?
If you're using QEMU to simulate an embedded platform (ARM or PPC based
for instance). There is a huge amount of variety in embedded platforms
so having to hard code the PC description as a machine type in QEMU is
kind of annoying.
>>> A managed system will want to supply arguments out of a central
>>> database. For a management-less use case, the config file is a hassle.
>>>
>>
>> As long as all options are still settable via command line (or
>> stdio), then it's not at all a hassle.
>>
>
> Yes. But if you don't plan to use it, why implement it?
Well, I do plan to use it. I'm simply saying that you don't have to use
it if you don't want to.
There are a lot of knobs in QEMU and most of them have somewhat
arbitrary defaults. For instance, when I setup a machine, I don't want
to use user networking by default, I want to use tap. A global
configuration file would be terribly useful for this sort of thing.
> My feeling is that config files are outdated. When used with a gui,
> you end up writing silly parsers and stuff and still wrecking things
> horribly when the the gui writer's expectations don't match reality.
> When used without a gui, they increase the amount of details one has
> to remember (where's that config file? I renamed my image, did I
> remember to update the config file?). They also make upgrading more
> difficult.
There's only so much that can be expressed on a command line. There are
actually limits to the command line size on a lot of platforms. I don't
see why reading options from a file is so much worse than reading them
from the command line.
Regards,
Anthony Liguori
>
>
>
next prev parent reply other threads:[~2007-08-10 20:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-10 4:55 Storing command line options in images Jorge Lucángeli Obes
2007-08-10 4:55 ` [Qemu-devel] " Jorge Lucángeli Obes
[not found] ` <59abf66e0708092155t2e3cd5o32f23c018bed65af-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-08-10 16:02 ` Anthony Liguori
2007-08-10 16:02 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
[not found] ` <46BC8C18.6020108-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-08-10 17:14 ` [Qemu-devel] " Avi Kivity
2007-08-10 17:14 ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
[not found] ` <46BC9CDB.3080900-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-08-10 18:43 ` [Qemu-devel] " Anthony Liguori
2007-08-10 18:43 ` [kvm-devel] " Anthony Liguori
[not found] ` <46BCB1DA.6060102-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-08-10 19:41 ` Avi Kivity
2007-08-10 19:41 ` [kvm-devel] " Avi Kivity
[not found] ` <46BCBF73.5060406-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-08-10 20:11 ` Anthony Liguori [this message]
2007-08-10 20:11 ` Anthony Liguori
[not found] ` <46BCC666.6050406-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-08-11 1:41 ` Jorge Lucángeli Obes
2007-08-11 1:41 ` [kvm-devel] " Jorge Lucángeli Obes
[not found] ` <59abf66e0708101841i76e26a35vcbc8df14b21f1ac0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-08-13 8:55 ` Avi Kivity
2007-08-13 8:55 ` [kvm-devel] " Avi Kivity
[not found] ` <46C01C8D.3060304-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-08-13 9:19 ` Laurent Vivier
2007-08-13 9:19 ` [kvm-devel] " Laurent Vivier
2007-08-13 9:27 ` [kvm-devel] " Christian MICHON
2007-08-13 9:27 ` [kvm-devel] [Qemu-devel] " Christian MICHON
2007-08-14 14:18 ` [kvm-devel] " Markus Hitter
2007-08-14 14:18 ` [kvm-devel] [Qemu-devel] " Markus Hitter
[not found] ` <F213D784-7927-4233-BD3E-57A808D31FE7-5aU9hSJ5JWgb1SvskN2V4Q@public.gmane.org>
2007-08-14 14:31 ` Laurent Vivier
2007-08-14 14:31 ` [kvm-devel] " Laurent Vivier
[not found] ` <46C1BCAC.9030203-6ktuUTfB/bM@public.gmane.org>
2007-08-14 19:02 ` Jorge Lucángeli Obes
2007-08-14 19:02 ` [kvm-devel] " Jorge Lucángeli Obes
[not found] ` <59abf66e0708141202t4eaf009cs4596cc76a164e3de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-08-14 20:07 ` Thiemo Seufer
2007-08-14 20:07 ` [kvm-devel] " Thiemo Seufer
[not found] ` <20070814200757.GA7685-eH4hzgmiRX8dwXzzRB9H2Q@public.gmane.org>
2007-08-14 20:46 ` Christian MICHON
2007-08-14 20:46 ` [kvm-devel] " Christian MICHON
2007-08-13 19:39 ` [kvm-devel] " Thiemo Seufer
2007-08-13 19:39 ` [kvm-devel] [Qemu-devel] " Thiemo Seufer
[not found] ` <20070813193927.GA21215-eH4hzgmiRX8dwXzzRB9H2Q@public.gmane.org>
2007-08-13 20:26 ` Christian MICHON
2007-08-13 20:26 ` [kvm-devel] " Christian MICHON
2007-08-14 3:17 ` Anthony Liguori
2007-08-14 3:17 ` [kvm-devel] " Anthony Liguori
2007-08-14 4:39 ` Jorge Lucángeli Obes
2007-08-14 4:39 ` [kvm-devel] " Jorge Lucángeli Obes
2007-08-14 7:44 ` Kevin Wolf
2007-08-13 22:21 ` Philip Boulain
2007-08-13 22:27 ` [Qemu-devel] Re: [kvm-devel] " Jernej Simončič
2007-08-13 23:31 ` [kvm-devel] [Qemu-devel] " Thiemo Seufer
2007-08-14 14:26 ` Philip Boulain
2007-08-14 7:46 ` [kvm-devel] " Laurent Vivier
2007-08-14 7:46 ` [kvm-devel] [Qemu-devel] " Laurent Vivier
[not found] ` <46C15DCE.1000205-6ktuUTfB/bM@public.gmane.org>
2007-08-15 21:26 ` Segher Boessenkool
2007-08-15 21:26 ` [kvm-devel] " Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BCC666.6050406@codemonkey.ws \
--to=anthony-rdkfgonbjusknkdkm+me6a@public.gmane.org \
--cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.