> Why not just bypass the whole config file idea and just use enviornment
> variables?
Absolutely not. Environment variables are a horrid way of configuring things.
Paul
-
This SF.net email is sponsored by: Microsoft
Defy
andrzej zaborowski writes ("Re: [Qemu-devel] Re: [PATCH] Add support for a
configuration file"):
> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.
cpp is a terrible preprocessor. It mostly works for C source code
(although
Le jeudi 15 mai 2008 à 15:04 +0300, Avi Kivity a écrit :
> Daniel P. Berrange wrote:
> > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> >
> >> Daniel P. Berrange wrote:
> >>
> >>> With this kind of syntax, now tools generating config files need to make
> >>> up unique names f
Daniel P. Berrange wrote:
> On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> With this kind of syntax, now tools generating config files need to make
>>> up unique names for each drive. So you'll probably end up with them just
>>> naming thin
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> >With this kind of syntax, now tools generating config files need to make
> >up unique names for each drive. So you'll probably end up with them just
> >naming things based on the class name + a number appende
Daniel P. Berrange wrote:
> With this kind of syntax, now tools generating config files need to make
> up unique names for each drive. So you'll probably end up with them just
> naming things based on the class name + a number appended.
>
I would hope that tools don't have to resort to reading
Paul Brook wrote:
>> I suggested it because my original plan for the configuration file was
>> based on this syntax with a strong inspiration from the OpenFirmware
>> device tree. The idea was that the object name ("drive" here) had no
>> hardcoded meaning, except for some predefined object names i
On Wed, 14 May 2008, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 14 May 2008, Javier Guerra wrote:
>
>> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
>> <[EMAIL PROTECTED]> wrote:
>>> On Wed, 14 May 2008, Javier Guerra wrote:
>>> > What about Lua? (http://www.lua.org)
>>> >
>>> > it sta
On Wed, May 14, 2008 at 10:37 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
> On Wed, 14 May 2008, Javier Guerra wrote:
> > when embedded, you get to choose what libraries are available. there
> > are several examples of fairly secure settings.
>
> Why artificially make it complicated, and
Hi,
On Wed, 14 May 2008, Javier Guerra wrote:
> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 14 May 2008, Javier Guerra wrote:
> > > What about Lua? (http://www.lua.org)
> > >
> > > it started up as a configuration language, and evolved into
On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
> On Wed, 14 May 2008, Javier Guerra wrote:
> > What about Lua? (http://www.lua.org)
> >
> > it started up as a configuration language, and evolved into a full
> > programming language, while remaining _very_ lig
On Wed, May 14, 2008 at 09:45:02AM -0500, Javier Guerra wrote:
> What about Lua? (http://www.lua.org)
>
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed in
On Wednesday 14 May 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> >> the "class" field is used to select the device model. Then all the other
> >> parameters are used to initialize the device model. That way it is
> >> possible to keep the compatibility with the existing options and add a
> >>
Dor Laor wrote:
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
>
> Please don't jump over me but I think it is worth mentioning OVF, at
> least for to know what's you opinions.
>
> Open Virtualization Format -
> http://www.vmware.com/appliances/learn/ovf.html
>
> It's xml based, supporte
Hi,
On Wed, 14 May 2008, Javier Guerra wrote:
> What about Lua? (http://www.lua.org)
>
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed into C programs.
Hi,
On Wed, 14 May 2008, andrzej zaborowski wrote:
> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.
This will add a dependency to a developer's tool on an application that
has not much to do with development for most use
Paul Brook wrote:
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such
On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote:
>
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> > Daniel P. Berrange wrote:
> > > That's very nearly YAML format[1], which is attractive because parsers
> > > are available in every major programming language, and it is still
> >
Avi Kivity wrote:
> Daniel P. Berrange wrote:
>> That's very nearly YAML format[1], which is attractive because parsers
>> are available in every major programming language, and it is still
>> pretty human friendly.
>>
>> So my preference would be to go with the last option and make sure
>> it real
On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> > That's very nearly YAML format[1], which is attractive because parsers
> > are available in every major programming language, and it is still
> > pretty human friendly.
> >
> > So my preference would be to go with
What about Lua? (http://www.lua.org)
it started up as a configuration language, and evolved into a full
programming language, while remaining _very_ light (less than 200K
with all libraries), and wonderfully easy to embed into C programs.
it lets you write things like:
drives = {
hda = {if='s
Daniel P. Berrange wrote:
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.
>
> So my preference would be to go with the last option and make sure
> it really is YAML compliant so pe
On 14/05/2008, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
>
> > I think this is pretty useful as-is. I think it also gives us a
> reasonable
> > way to move forward that will keep everyone pretty happy.
> >
> > Here's a short example:
> >
> > qemu-system-x86_64 -hda ~/imag
> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a ki
Fabrice Bellard wrote:
> Avi Kivity wrote:
>> Fabrice Bellard wrote:
>>>
>>> I prefer:
>>>
>>> drive.file=foo.img
>>> drive.if=scsi
>>>
>>
>> That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested it because my original plan for the configuration file
On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote:
> Avi Kivity wrote:
> > Fabrice Bellard wrote:
> >>
> >> I prefer:
> >>
> >> drive.file=foo.img
> >> drive.if=scsi
> >>
> >
> > That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested i
Avi Kivity wrote:
> Fabrice Bellard wrote:
>>
>> I prefer:
>>
>> drive.file=foo.img
>> drive.if=scsi
>>
>
> That doesn't support multiple drives very well.
Right, I realized it afterwards !
I suggested it because my original plan for the configuration file was
based on this syntax with a strong
Fabrice Bellard wrote:
>
> I prefer:
>
> drive.file=foo.img
> drive.if=scsi
>
That doesn't support multiple drives very well.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.
While YAML is certainly human readable, it's not very "human writable" IMHO. I
think that a simpler format would be more appropiat
Anthony Liguori wrote:
> One thought I had, is that it would be very nice to break up the -drive
> file=foo.img,if=scsi syntax within the config file. In general, I'm
> thinking something like:
>
> [drive]
> file=foo.img
> if=scsi
>
> or:
>
> drive {
> file=foo.img
> if=scsi
> }
>
> or e
30 matches
Mail list logo
