On 11 June 2012 14:12, Anthony Liguori wrote:
> I really don't see the overwhelming need to keep structures private. Being
> able to directly reference public members is extremely handy.
It keeps people honest. Last time I looked at your pin series it had
some changes which were using private in
On 06/11/2012 02:20 AM, Paolo Bonzini wrote:
Il 11/06/2012 09:13, Andreas Färber ha scritto:
+The first step is to move your device struct definition to a header file. This
+header file should only contain the struct definition and any preprocessor
+declarations you need to define the structure
On 11 June 2012 08:13, Andreas Färber wrote:
> Am 05.06.2012 12:00, schrieb Peter Maydell:
>> I don't think this is a fantastic idea -- the device struct should be
>> private to the device, and having it in a standalone header file is
>> asking for users of the device to illicitly include it and a
Am 11.06.2012 09:59, schrieb Paolo Bonzini:
> Il 11/06/2012 09:56, Andreas Färber ha scritto:
I thought that was just a convenience choice, not a necessity. The
children objects could just as well be heap-allocated.
>> In that case we'd need to change the instance_init signature. As far
Am 11.06.2012 09:56, schrieb Andreas Färber:
> Am 11.06.2012 09:20, schrieb Paolo Bonzini:
>> Il 11/06/2012 09:13, Andreas Färber ha scritto:
>>> +The first step is to move your device struct definition to a header
>>> file. This
>>> +header file should only contain the struct definit
Il 11/06/2012 09:56, Andreas Färber ha scritto:
>> > I thought that was just a convenience choice, not a necessity. The
>> > children objects could just as well be heap-allocated.
> In that case we'd need to change the instance_init signature. As far as
> I've understood from our discussions with
Am 11.06.2012 09:20, schrieb Paolo Bonzini:
> Il 11/06/2012 09:13, Andreas Färber ha scritto:
>> +The first step is to move your device struct definition to a header
>> file. This
>> +header file should only contain the struct definition and any
>> preprocessor
>> +declaratio
Il 11/06/2012 09:13, Andreas Färber ha scritto:
>>> >> +The first step is to move your device struct definition to a header
>>> >> file. This
>>> >> +header file should only contain the struct definition and any
>>> >> preprocessor
>>> >> +declarations you need to define the structure. This hea
Am 05.06.2012 12:00, schrieb Peter Maydell:
> On 5 June 2012 02:00, Michael Roth wrote:
>> +The first step is to move your device struct definition to a header file.
>> This
>> +header file should only contain the struct definition and any preprocessor
>> +declarations you need to define the str
On 06/07/2012 12:36 AM, Michael Roth wrote:
> It would need to be something fairly ubiquitous though, and pygments is
> the more well-used library yet still isn't available on RHEL5 and
> probably a few other distros we need to support.
If someone wants to build qemu from source on RHEL5, they can
On 06/05/2012 06:06 PM, Avi Kivity wrote:
On 06/05/2012 04:00 AM, Michael Roth wrote:
This is an import of Anthony's qidl compiler, with some changes squashed
in to add support for doing the visitor generation via QEMU's qapi code
generators rather than directly.
Documentation has been imported
On Wed, Jun 06, 2012 at 10:31:56AM +0300, Avi Kivity wrote:
> On 06/06/2012 12:11 AM, Michael Roth wrote:
> >>
> >> Is is possible to let the compiler process the .c file, with the IDL
> >> delimited by some marker? I like how device models are self contained
> >> in one file now.
> >
> > It's p
On 06/06/2012 02:12 PM, Anthony Liguori wrote:
> On 06/06/2012 05:58 PM, Avi Kivity wrote:
>> On 06/06/2012 12:17 PM, Anthony Liguori wrote:
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during in
On 06/06/2012 05:58 PM, Avi Kivity wrote:
On 06/06/2012 12:17 PM, Anthony Liguori wrote:
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during initialization?
No, this would be wrong.
'_immutable' means that the *state
On 06/06/2012 12:17 PM, Anthony Liguori wrote:
>>
>> So, is it reasonable to say
>>
>>uint32_t * _immutable irrp; // Interrupt Request Register
>>
>> and allocate it on the heap during initialization?
>
> No, this would be wrong.
>
> '_immutable' means that the *state* is immutable from the
On 06/06/2012 04:59 PM, Avi Kivity wrote:
On 06/06/2012 11:45 AM, Anthony Liguori wrote:
Ok. But then the backend pointer is not 'const Backend * const', it's
'Backend * const' (if we don't allow retargeting). So we can't say it's
_immutable (and it isn't). It's _host.
'Backend * const' is
On 06/06/2012 11:45 AM, Anthony Liguori wrote:
>> Ok. But then the backend pointer is not 'const Backend * const', it's
>> 'Backend * const' (if we don't allow retargeting). So we can't say it's
>> _immutable (and it isn't). It's _host.
>
> 'Backend * const' is immutable
>
> That is, the *poin
On 06/06/2012 04:37 PM, Avi Kivity wrote:
On 06/06/2012 11:27 AM, Anthony Liguori wrote:
On 06/06/2012 03:45 PM, Avi Kivity wrote:
I think you meant to add a const in there, but yeah, I know.
Maybe also a _stupid. How can one get a one line example wrong by
omitting the important word out of
On 06/06/2012 11:27 AM, Anthony Liguori wrote:
> On 06/06/2012 03:45 PM, Avi Kivity wrote:
>> On 06/06/2012 02:51 AM, Anthony Liguori wrote:
> +during device construction and never changes. This means we can
> add an
> +**_immutable** marker to it:
Even if it does change (sup
On 06/06/2012 03:45 PM, Avi Kivity wrote:
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
+during device construction and never changes. This means we can add an
+**_immutable** marker to it:
Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), i
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
>>> +during device construction and never changes. This means we can add an
>>> +**_immutable** marker to it:
>>
>> Even if it does change (suppose we add a monitor command to retarget a
>> the serial device's chardev), it need not be migrated since i
On 06/06/2012 12:11 AM, Michael Roth wrote:
>>
>> Is is possible to let the compiler process the .c file, with the IDL
>> delimited by some marker? I like how device models are self contained
>> in one file now.
>
> It's possible, but only if we inject the generated visitor code into the
> devic
Am 05.06.2012 18:21, schrieb Michael Roth:
> On Tue, Jun 05, 2012 at 11:25:01AM +0200, Kevin Wolf wrote:
>> Am 05.06.2012 03:00, schrieb Michael Roth:
>>> This is an import of Anthony's qidl compiler, with some changes squashed
>>> in to add support for doing the visitor generation via QEMU's qapi
On 06/05/2012 03:19 PM, Gerd Hoffmann wrote:
> Hi,
>
>>
>>
>> Suggestion: add a _guest marker for ordinary state. Fail the build on
>> unmarked fields. This ensures that some thought is given to each field,
>> instead of having a default that may be correct most of the time, but
>> not alway
On 06/06/2012 01:12 PM, Paolo Bonzini wrote:
Il 06/06/2012 01:40, Anthony Liguori ha scritto:
The only way I can think of getting around this is to do nasty things
like adding an
#include "qapi-generated/mc146818rtc-qapi-visit.c";
in hw/mc146818rtc.c.
It doesn't look that ugly, though perh
Il 06/06/2012 01:40, Anthony Liguori ha scritto:
>>
>>> The only way I can think of getting around this is to do nasty things
>>> like adding an
>>>
>>> #include "qapi-generated/mc146818rtc-qapi-visit.c";
>>>
>>> in hw/mc146818rtc.c.
>>
>> It doesn't look that ugly, though perhaps I'm biased becaus
On 6 June 2012 00:51, Anthony Liguori wrote:
> In the case of a CharDriverState, the reference is always immutable. If we
> supported changing char backends dynamically, it would not happen by
> changing the reference, but almost certainly by having the ability to reopen
> the char driver in plac
On 06/05/2012 06:06 PM, Avi Kivity wrote:
On 06/05/2012 04:00 AM, Michael Roth wrote:
In addition, QC can decide at run time whether to
+suppress a field by assigning it a **default** value.
+
+## Immutable Fields
+
+If a field is only set during device construction, based on parameters passed
On 06/06/2012 03:56 AM, Paolo Bonzini wrote:
Il 05/06/2012 18:21, Michael Roth ha scritto:
The only way I can think of getting around this is to do nasty things
like adding an
#include "qapi-generated/mc146818rtc-qapi-visit.c";
in hw/mc146818rtc.c.
It doesn't look that ugly, though perhaps I
On 06/05/2012 08:19 PM, Gerd Hoffmann wrote:
Hi,
Suggestion: add a _guest marker for ordinary state. Fail the build on
unmarked fields. This ensures that some thought is given to each field,
instead of having a default that may be correct most of the time, but
not always.
Suggestion: ad
On Tue, Jun 05, 2012 at 01:06:10PM +0300, Avi Kivity wrote:
> On 06/05/2012 04:00 AM, Michael Roth wrote:
> > This is an import of Anthony's qidl compiler, with some changes squashed
> > in to add support for doing the visitor generation via QEMU's qapi code
> > generators rather than directly.
> >
Il 05/06/2012 18:21, Michael Roth ha scritto:
> The only way I can think of getting around this is to do nasty things
> like adding an
>
> #include "qapi-generated/mc146818rtc-qapi-visit.c";
>
> in hw/mc146818rtc.c.
It doesn't look that ugly, though perhaps I'm biased because that's
again exactl
On Tue, Jun 05, 2012 at 11:25:01AM +0200, Kevin Wolf wrote:
> Am 05.06.2012 03:00, schrieb Michael Roth:
> > This is an import of Anthony's qidl compiler, with some changes squashed
> > in to add support for doing the visitor generation via QEMU's qapi code
> > generators rather than directly.
> >
Hi,
>
>
> Suggestion: add a _guest marker for ordinary state. Fail the build on
> unmarked fields. This ensures that some thought is given to each field,
> instead of having a default that may be correct most of the time, but
> not always.
>
> Suggestion: add a mandatory position hint (_gue
Am 05.06.2012 11:47, schrieb Anthony Liguori:
> On 06/05/2012 05:25 PM, Kevin Wolf wrote:
>> Am 05.06.2012 03:00, schrieb Michael Roth:
>>> This is an import of Anthony's qidl compiler, with some changes squashed
>>> in to add support for doing the visitor generation via QEMU's qapi code
>>> genera
On 06/05/2012 06:00 PM, Peter Maydell wrote:
On 5 June 2012 02:00, Michael Roth wrote:
+The first step is to move your device struct definition to a header file. This
+header file should only contain the struct definition and any preprocessor
+declarations you need to define the structure. Th
On 06/05/2012 04:00 AM, Michael Roth wrote:
> This is an import of Anthony's qidl compiler, with some changes squashed
> in to add support for doing the visitor generation via QEMU's qapi code
> generators rather than directly.
>
> Documentation has been imported as well, as is also viewable at:
>
On 5 June 2012 02:00, Michael Roth wrote:
> +The first step is to move your device struct definition to a header file.
> This
> +header file should only contain the struct definition and any preprocessor
> +declarations you need to define the structure. This header file will act as
> +the sourc
On 06/05/2012 05:25 PM, Kevin Wolf wrote:
Am 05.06.2012 03:00, schrieb Michael Roth:
This is an import of Anthony's qidl compiler, with some changes squashed
in to add support for doing the visitor generation via QEMU's qapi code
generators rather than directly.
Documentation has been imported
Am 05.06.2012 03:00, schrieb Michael Roth:
> This is an import of Anthony's qidl compiler, with some changes squashed
> in to add support for doing the visitor generation via QEMU's qapi code
> generators rather than directly.
>
> Documentation has been imported as well, as is also viewable at:
>
This is an import of Anthony's qidl compiler, with some changes squashed
in to add support for doing the visitor generation via QEMU's qapi code
generators rather than directly.
Documentation has been imported as well, as is also viewable at:
https://github.com/aliguori/qidl/blob/master/qc.md
Th
Hi,
Thanks for sending this Mike. If you're on CC, please do read the qc.md at
least. There is a good bit of theory here about how to rigorously approach
serialization of device state. I think the approach is sound and could solve a
lot of the problems we face today but it could use review.
42 matches
Mail list logo
