From: "Andreas Färber" <andreas.faerber@web.de>
To: Alex Horn <alex.horn@cs.ox.ac.uk>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH v2 7/7] tmp105: Add temperature QOM property
Date: Sat, 15 Dec 2012 19:30:47 +0100 [thread overview]
Message-ID: <50CCC1D7.2080904@web.de> (raw)
In-Reply-To: <CAN1LFUMbxuscm49tTquj_yqcNXisJv4MFWH-bmc9=vebWXUWtw@mail.gmail.com>
Am 15.12.2012 17:52, schrieb Alex Horn:
>> +static void tmp105_initfn(Object *obj)
>> +{
>> + object_property_add(obj, "temperature", "int",
>> + tmp105_get_temperature,
>> + tmp105_set_temperature, NULL, NULL, NULL);
>> +}
>> +
>> static void tmp105_class_init(ObjectClass *klass, void *data)
>> {
>> DeviceClass *dc = DEVICE_CLASS(klass);
>> @@ -234,6 +258,7 @@ static const TypeInfo tmp105_info = {
>> .name = TYPE_TMP105,
>> .parent = TYPE_I2C_SLAVE,
>> .instance_size = sizeof(TMP105State),
>> + .instance_init = tmp105_initfn,
>> .class_init = tmp105_class_init,
>> };
>>
>> diff --git a/hw/tmp105.h b/hw/tmp105.h
>> index c21396f..d218919 100644
>> --- a/hw/tmp105.h
>> +++ b/hw/tmp105.h
>> @@ -44,19 +44,4 @@ typedef struct TMP105State {
>> uint8_t alarm;
>> } TMP105State;
>>
>> -/**
>> - * tmp105_set:
>> - * @i2c: dispatcher to TMP105 hardware model
>> - * @temp: temperature with 0.001 centigrades units in the range -40 C to +125 C
>> - *
>> - * Sets the temperature of the TMP105 hardware model.
>> - *
>> - * Bits 5 and 6 (value 32 and 64) in the register indexed by TMP105_REG_CONFIG
>> - * determine the precision of the temperature. See Table 8 in the data sheet.
>> - *
>> - * @see_also: I2C_SLAVE macro
>> - * @see_also: http://www.ti.com/lit/gpn/tmp105
>> - */
>> -void tmp105_set(I2CSlave *i2c, int temp);
>
> Would it be possible to keep the C API? The traditional C API is
> useful when a project cannot support QOM. These C APIs also simplify
> unit testing and allow QEMU hardware models to be more easily reused
> as standalone modules.
QEMU devices are meant to be instantiated through QOM, and the use of
QOM is gradually increasing (it was introduced around last Christmas).
So while it would be possible to leave tmp105_set() behind as wrapper for
Error *err = NULL;
object_property_set_int(OBJECT(i2c), "temperature", temp, err);
if (err != NULL) {
fprintf(stderr, "%s", error_get_pretty(err));
error_free(err);
exit(-1);
}
it uses a very fatal way of error handling and, as you said yourself,
has zero users in qemu.git.
By comparison the QOM property in this patch allows to set the value via
C API or QMP commands, including scripts such as QMP/qom-set or
QMP/qom-fuse.
So I don't see why the effort? What project are you trying to reuse QEMU
devices in without using QEMU's device infrastructure? Not even Xen did
that AFAIK. If you're trying to integrate with SystemC or so there are
some (possibly not quite up-to-date) projects (e.g., linked from the
Wiki) to bridge worlds.
Regards,
Andreas
next prev parent reply other threads:[~2012-12-15 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 11:34 [Qemu-devel] [PATCH v2 0/7] I2C libqos and tmp105 qtest support Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 1/7] tmp105: Create API for TMP105 temperature sensor Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 2/7] libqtest: Prepare I2C libqos Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 3/7] tmp105: Split out I2C message constants from header Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 4/7] tests: Add tmp105 qtest test case Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 5/7] tmp105: Fix I2C protocol bug Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 6/7] tmp105: QOM'ify Andreas Färber
2012-12-14 11:34 ` [Qemu-devel] [PATCH v2 7/7] tmp105: Add temperature QOM property Andreas Färber
2012-12-15 16:52 ` Alex Horn
2012-12-15 18:30 ` Andreas Färber [this message]
2013-01-06 21:07 ` [Qemu-devel] [PATCH v2 0/7] I2C libqos and tmp105 qtest support Andreas Färber
2013-01-07 19:36 ` Anthony Liguori
2013-01-07 19:37 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50CCC1D7.2080904@web.de \
--to=andreas.faerber@web.de \
--cc=alex.horn@cs.ox.ac.uk \
--cc=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).