qemu-devel
[Top][All Lists]
Advanced

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

Re: Making QEMU easier for management tools and applications


From: John Snow
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 27 Jan 2020 19:37:27 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0


On 1/27/20 5:38 PM, Paolo Bonzini wrote:
> 
> 
> Il lun 27 gen 2020, 21:11 John Snow <address@hidden
> <mailto:address@hidden>> ha scritto:
> 
> 
>     > ./qemu-core <<EOF
>     {
>         "machine": "Q35",
>         "memory": "2GiB",
>         "accel": "kvm"
>     }
>     EOF
> 
> 
> And now you have to keep all the syntactic sugar that is in vl.c. I

Didn't mean to suggest literal values, I just grabbed some from the top
of my head. Let's pretend I didn't use sugared ones. This is a
distraction from the point.

The point is: you can specify JSON on the command line, as stdin to QEMU
as a here document. No config file needed.

> don't think a redesign of -readconfig should accept anything less
> verbose than
> 
> - machine:
>     type: q35
>     ram:
>        type: memory-backend-hostmem
>        size: 2G
> - accel:
>   - type: kvm
> 
> And this is not even taking into account disks.
> 

Though, point taken, even minimal configurations might get too cumbersome.

> I like the idea of refactoring all the syntactic sugar into a pre-pass
> on command line options. This is not an entirely new idea,
> see https://www.mail-archive.com/address@hidden/msg35024.html.

This could be very good, as long as the transformation was knowable in
some way. (Documented, modeled in the schema somehow, observable
post-transformation, whichever.)

(wow, 2010.)

> 
> I am afraid that this thread is derailing a bit, with lots of pipe
> dreams and no actionable items. How do we get it back in track?
> 

That depends on what your opinion of "on track" is. If there are
specific angles you find interesting, it would be easiest to start a
thread around the framing you find productive.

--js




reply via email to

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