> On 24 Jun 2015, at 17:11, Liviu Ionescu wrote:
>
> ... it might very well be C++, with some wrappers ...
unfortunately this is not technically feasible, for many reasons, one of them
being the 'struct Object' member named 'class' :-(
regards,
Liviu
Am 24.06.2015 um 16:39 schrieb Liviu Ionescu:
>
>> On 24 Jun 2015, at 17:18, Andreas Färber wrote:
>>
>> ... our Coding Style.
>
> sorry, but I checked both QEMU Coding Style and QEMU Coding Guidelines and
> could not find any rule forbidding the use of blocks for introducing local
> scopes.
> On 24 Jun 2015, at 17:18, Andreas Färber wrote:
>
> ... our Coding Style.
sorry, but I checked both QEMU Coding Style and QEMU Coding Guidelines and
could not find any rule forbidding the use of blocks for introducing local
scopes.
regards,
Liviu
Am 24.06.2015 um 16:11 schrieb Liviu Ionescu:
> On 24 Jun 2015, at 16:50, Andreas Färber wrote:
>
>> You're still doing the {...} thing I asked you not to do.
>
> thank you for your suggestions.
It's not a suggestion. Our Coding Style is a mandatory requirement for
code review. I already pointe
> On 24 Jun 2015, at 16:50, Andreas Färber wrote:
>
> You're still doing the {...} thing I asked you not to do.
thank you for your suggestions.
right now I'm more concerned on which APIs to use, and my current understanding
is that you prefer direct QOM calls over QDev, which are deprecated.
Am 24.06.2015 um 11:29 schrieb Liviu Ionescu:
> the machine init code now looks like this:
>
> static void stm32_h103_board_init_callback(MachineState *machine)
> {
> cm_board_greeting(machine);
>
> {
> /* Create the MCU */
> DeviceState *mcu = cm_create(TYPE_STM32F103RB);
Am 24.06.2015 um 11:51 schrieb Paolo Bonzini:
> On 24/06/2015 11:29, Liviu Ionescu wrote:
>> ok, I managed to restructure my code to get rid of the explicit
>> constructor. :-)
>>
>> I also avoided properties aliases, and did prop setting in two steps,
>> in machine init I set props in MCU, and fro
On 24/06/2015 11:29, Liviu Ionescu wrote:
> ok, I managed to restructure my code to get rid of the explicit
> constructor. :-)
>
> I also avoided properties aliases, and did prop setting in two steps,
> in machine init I set props in MCU, and from here I manually set them
> in specific periphera
> On 24 Jun 2015, at 11:29, Peter Crosthwaite
> wrote:
>
>>
>> Peter C, is this solution acceptable?
>>
>
> Settable props are generally acceptable, but it is unusual for a
> machine init routine.
ok, I managed to restructure my code to get rid of the explicit constructor. :-)
I also avoid
On 23/06/2015 22:10, Liviu Ionescu wrote:
> I suggest your review should start from use cases like this:
>
> DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
> my_dev_prop_set_bool(dev, "param", true);
> my_dev_construct(OBJECT(dev), NULL);
> my_dev_prop_set_uint32(dev, "xyz",
On Wed, Jun 24, 2015 at 12:30 AM, Liviu Ionescu wrote:
>
>> On 23 Jun 2015, at 23:10, Liviu Ionescu wrote:
>>
>> another solution would look like:
>>
>>DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
>>my_dev_prop_set_string(dev, "param", "something");
>>my_dev_realize(dev);
>>
> On 23 Jun 2015, at 23:10, Liviu Ionescu wrote:
>
> another solution would look like:
>
>DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
>my_dev_prop_set_string(dev, "param", "something");
>my_dev_realize(dev);
>my_dev_prop_set_uint32(dev, "xyz", 123);
>
> which obviously
> On 23 Jun 2015, at 23:57, Peter Crosthwaite
> wrote:
>
> Give it a go and let me know where it gets stuck.
I sent you a Skype invitation, but apparently it did not pass through. could
you try from your side (my id is 'ilg-ul').
regards,
Liviu
On Tue, Jun 23, 2015 at 12:10 PM, Liviu Ionescu wrote:
>
>> On 23 Jun 2015, at 21:31, Peter Crosthwaite
>> wrote:
>>
>> List discussions should be fine, regardless of release cycle phase.
>
> I apologise to all those who considered my messages not appropriate for this
> list or for this moment.
> On 23 Jun 2015, at 21:31, Peter Crosthwaite
> wrote:
>
> I will review it on list and see if I can think of alternate
> construction sequence.
I suggest your review should start from use cases like this:
DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
my_dev_prop_set_bool(dev, "
Am 23.06.2015 um 20:31 schrieb Peter Crosthwaite:
> On Tue, Jun 23, 2015 at 7:25 AM, Andreas Färber wrote:
>> Am 23.06.2015 um 14:58 schrieb Liviu Ionescu:
>>> could you provide more details to identify this thread?
>>
>> No, I'm not going to do all your work! You're papering the list with
>> RFCs
> On 23 Jun 2015, at 21:31, Peter Crosthwaite
> wrote:
>
> List discussions should be fine, regardless of release cycle phase.
I apologise to all those who considered my messages not appropriate for this
list or for this moment.
> ... usually you see these kind of needs once you see the code
On Tue, Jun 23, 2015 at 7:25 AM, Andreas Färber wrote:
> Am 23.06.2015 um 14:58 schrieb Liviu Ionescu:
>>> On 23 Jun 2015, at 13:39, Andreas Färber wrote:
>>>
>>> ... that spares indentation.
>>
>> indentation? I'm not doing it manually, I just press a key combination in my
>> Eclipse and indent
> On 23 Jun 2015, at 17:25, Andreas Färber wrote:
>
> ... I honestly don't understand what you're arguing here... Your
> code examples are not telling.
:-(
> Are you maybe missing that there are dynamic QOM properties in addition
> to the qdev properties you use in your examples?
/* A
Am 23.06.2015 um 14:58 schrieb Liviu Ionescu:
>> On 23 Jun 2015, at 13:39, Andreas Färber wrote:
>>
>> ... that spares indentation.
>
> indentation? I'm not doing it manually, I just press a key combination in my
> Eclipse and indentation is done auto-magically.
Dude, we don't care *how* you in
> On 23 Jun 2015, at 13:39, Andreas Färber wrote:
>
> ... that spares indentation.
indentation? I'm not doing it manually, I just press a key combination in my
Eclipse and indentation is done auto-magically.
> Please don't add new infrastructure with "qdev" in the name, qdev was
> the old dev
Hi Liviu,
Am 15.06.2015 um 15:35 schrieb Liviu Ionescu:
>> On 15 Jun 2015, at 13:48, Liviu Ionescu wrote:
>>
>> ... One natural solution would be to add an explicit constructor, like in
>> C++.
>
> if this solution is considered too complicated, it might also be possible to
> arrange for the
> On 23 Jun 2015, at 10:47, Markus Armbruster wrote:
>
> Copying Andreas.
Hallo Andreas!
Liviu
Copying Andreas.
Liviu Ionescu writes:
> after some more experimenting, here are the conclusions:
>
> - I added a new .construct pointer to all my classes:
>
> void (*construct)(Object *obj, void *data);
>
> the 'data' pointer is optional, for qdev calls, parameters should be passed
> via p
after some more experimenting, here are the conclusions:
- I added a new .construct pointer to all my classes:
void (*construct)(Object *obj, void *data);
the 'data' pointer is optional, for qdev calls, parameters should be passed via
properties.
- constructors should manually call their
> On 15 Jun 2015, at 13:48, Liviu Ionescu wrote:
>
> ... One natural solution would be to add an explicit constructor, like in
> C++.
if this solution is considered too complicated, it might also be possible to
arrange for the constructor data to be passed to the existing .instance_init
cal
> On 15 Jun 2015, at 13:48, Liviu Ionescu wrote:
>
> ... add an explicit constructor, like in C++.
> ... the DeviceClass structure ... qdev_construct() ...
For more generality, the new construct/destruct pointers can be added directly
to the QOM ObjectClass, and the functions implemented as:
The .instance_init construction method available in the current QOM provides an
equivalent of the C++ default constructor, that works just fine as long as
there is no need to pass additional data to the construction logic.
One natural solution would be to add an explicit constructor, like in C++
28 matches
Mail list logo
