On 04/09/18 11:02, Kashyap Chamarthy wrote:
> - It also provides a persistent command history in a convenient file:
> '~/.qmp-shell_history'
I noticed it used readline, but I didn't know about the dedicated
history file. Nice! Thanks!
Laszlo
On Fri, Apr 06, 2018 at 08:21:00PM +0200, Laszlo Ersek wrote:
> On 04/06/18 20:10, Eric Blake wrote:
[...]
> # key=value pairs also support Python or JSON object literal subset notations,
> # without spaces. Dictionaries/objects {} are supported as are arrays [].
> #
> #example-command arg-na
On 04/06/18 20:10, Eric Blake wrote:
> On 04/06/2018 12:28 PM, Laszlo Ersek wrote:
>
>> I've created an RFC-level "qapi/firmware.json" schema file, based on
>> this discussion. It "builds", and the generated documentation looks
>> acceptable, superficially speaking.
>>
>> Before I post "qapi/firmwa
On 04/06/2018 12:28 PM, Laszlo Ersek wrote:
> I've created an RFC-level "qapi/firmware.json" schema file, based on
> this discussion. It "builds", and the generated documentation looks
> acceptable, superficially speaking.
>
> Before I post "qapi/firmware.json" for getting comments, I'd like to
>
On 03/08/18 11:17, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
[*] Open question: Who, between QEMU and libvirt, should define the said
firmware metadata format and file?
>>>
>>> IMHO QEMU should be defining the format, because th
On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote:
> On 03/08/18 16:47, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
>
> >> I suggest (or agree) that the property list be composed of free-form
> >> name=value pairs (at least conceptually).
On Fri, Mar 09, 2018 at 04:18:45PM +0100, Laszlo Ersek wrote:
> On 03/09/18 15:27, Gerd Hoffmann wrote:
> > Hi,
> >
> >> For OVMF (x86), I guess the initial set of properties should come from
> >> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
> >> might grow or change in
On 03/09/18 15:27, Gerd Hoffmann wrote:
> Hi,
>
>> For OVMF (x86), I guess the initial set of properties should come from
>> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
>> might grow or change incompatibly over time, so this is just a raw
>> starter idea.)
>
>> (0) AR
On 03/09/18 12:27, Kashyap Chamarthy wrote:
> On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote:
>> On 03/08/18 16:47, Daniel P. Berrangé wrote:
>>> On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
>
> [...]
>
For OVMF (x86), I guess the initial set of properties shou
Hi,
> For OVMF (x86), I guess the initial set of properties should come from
> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
> might grow or change incompatibly over time, so this is just a raw
> starter idea.)
> (0) ARCH (one of IA32, IA32X64, X64) -- the bitnesses of
On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote:
> On 03/08/18 16:47, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
[...]
> >> For OVMF (x86), I guess the initial set of properties should come from
> >> the "-D FOO[=BAR]" build flags that
On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > [*] Open question: Who, between QEMU and libvirt, should define the said
> > > firmware metadata format and file?
> >
> > IMHO QEMU should be defining the format, because the file will contain
> > info about certain QE
On 03/08/18 16:47, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
>> I suggest (or agree) that the property list be composed of free-form
>> name=value pairs (at least conceptually). I understand Gerd is proposing
>> a QAPI schema for this, so maybe do {
On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
> (
> Ard, the thread starts here:
>
> http://mid.mail-archive.com/20180307144951.d75lo5rgzi2vf27z@eukaryote
> )
>
> On 03/07/18 15:49, Kashyap Chamarthy wrote:
> > Problem background
> > --
> >
> > The various OVMF bi
(
Ard, the thread starts here:
http://mid.mail-archive.com/20180307144951.d75lo5rgzi2vf27z@eukaryote
)
On 03/07/18 15:49, Kashyap Chamarthy wrote:
> Problem background
> --
>
> The various OVMF binary file names and paths are slightly different[+]
> for each Linux distribution.
On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > [*] Open question: Who, between QEMU and libvirt, should define the said
> > > firmware metadata format and file?
> >
> > IMHO QEMU should be defining the format, because the file will contain
> > info about certain QE
On Thu, Mar 08, 2018 at 08:45:07AM +0100, Gerd Hoffmann wrote:
> > Suggested approach
> > --
> >
> > Based on an upstream discussion on 'virt-tools'[1] mailing list and some
> > Bugzillas, Gerd Hoffmann, Laszlo Ersek and Dan Berrangé had a suggestion
> > to define a firmware metada
Hi,
> > [*] Open question: Who, between QEMU and libvirt, should define the said
> > firmware metadata format and file?
>
> IMHO QEMU should be defining the format, because the file will contain
> info about certain QEMU features associated with the firmware (eg smm).
> Also there are potential
> Suggested approach
> --
>
> Based on an upstream discussion on 'virt-tools'[1] mailing list and some
> Bugzillas, Gerd Hoffmann, Laszlo Ersek and Dan Berrangé had a suggestion
> to define a firmware metadata format and file (example in [1]):
>
> - For each firmware file we nee
On Wed, Mar 07, 2018 at 03:49:51PM +0100, Kashyap Chamarthy wrote:
> Problem background
> --
>
> The various OVMF binary file names and paths are slightly different[+]
> for each Linux distribution. And each high-level management tool
> (libguestfs, oVirt, `virt-manager` and OpenS
Problem background
--
The various OVMF binary file names and paths are slightly different[+]
for each Linux distribution. And each high-level management tool
(libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
own approach to detect and configure the said OVMF
21 matches
Mail list logo
