From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
peter.maydell@linaro.org, aliguori@us.ibm.com, eblake@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] Add infrastructure for QIDL-based device serialization
Date: Tue, 25 Sep 2012 10:45:02 -0500 [thread overview]
Message-ID: <20120925154502.GW16157@illuin> (raw)
In-Reply-To: <5061511C.4040504@redhat.com>
On Tue, Sep 25, 2012 at 08:37:16AM +0200, Paolo Bonzini wrote:
> Il 24/09/2012 20:14, Michael Roth ha scritto:
> >>> > > I went with qUppercase because it avoids all the previous issues with
> >>> > > using leading underscores, and it's reserved in terms of QEMU coding
> >>> > > guidelines as far as I can tell (we generally require leading capital
> >>> > > for typedefs and lowercase for variable names, and can work around
> >>> > > exceptions on a case by case basis by using QIDL() or some other name).
> >>> > > I also had it as q_* for a bit but that didn't seem much better on the
> >>> > > eyes we looking at converted structures.
> >> >
> >> > It looks like Hungarian notation and very much unlike other QEMU code.
> >> > I'd use q_ or qidl_ prefix instead, or rather QIDL().
> >> >
> > I wanted some way to distinguish from other qemu code to avoid conflicts,
> > but i think q_* seems reasonable if we reserve the prefix via CODING_STYLE.
> > Then for conflicts outside our control we can either use a different name
> > for the annotations or use the long-form QIDL() style depending on the
> > circumstances.
>
> I'm not sure why we need two ways to say the same thing... I know it's
> just bikeshedding to some extent, but I'd really like to standardize on
> a single form.
QIDL() (or maybe qidl()) should be the One True Form. It's the
only one that provides both proper namespacing and can be used both for
simple annotations and for ones that take parameters.
I guess the real question is whether or not it makes sense to provide
"shortcuts" for the more common annotations to avoid clutter. I've heard
it both ways, so it's hard to decide.
So let's bikeshed a bit. Maybe to put things into perspective, we're looking
at (and I'm just gonna go ahead and switch the OTF to qidl() now so we're
looking at the best case scenarios for both, and include q_* as well):
a) One True Form:
QIDL_DECLARE(RTCState) {
ISADevice dev qidl(immutable);
MemoryRegion io qidl(immutable);
uint8_t cmos_data[128];
uint8_t cmos_index;
int32_t base_year qidl(property, "base_year", 1980);
uint64_t base_rtc;
uint64_t last_update;
int64_t offset;
qemu_irq irq qidl(immutable);
qemu_irq sqw_irq qidl(immutable);
int it_shift qidl(immutable);
/* periodic timer */
QEMUTimer *periodic_timer;
int64_t next_periodic_time;
/* update-ended timer */
QEMUTimer *update_timer;
uint64_t next_alarm_time;
uint16_t irq_reinject_on_ack_count qidl(broken);
uint32_t irq_coalesced;
uint32_t period;
bool has_coalesced_timer;
QEMUTimer *coalesced_timer qidl(optional);
Notifier clock_reset_notifier qidl(broken);
LostTickPolicy lost_tick_policy qidl(immutable) \
qidl(property, "lost_tick_policy", LOST_TICK_DISCARD);
Notifier suspend_notifier qidl(broken);
};
b) current simplified form:
QIDL_DECLARE(RTCState) {
ISADevice dev qImmutable;
MemoryRegion io qImmutable;
uint8_t cmos_data[128];
uint8_t cmos_index;
int32_t base_year qProperty("base_year", 1980);
uint64_t base_rtc;
uint64_t last_update;
int64_t offset;
qemu_irq irq qImmutable;
qemu_irq sqw_irq qImmutable;
int it_shift qImmutable;
/* periodic timer */
QEMUTimer *periodic_timer;
int64_t next_periodic_time;
/* update-ended timer */
QEMUTimer *update_timer;
uint64_t next_alarm_time;
uint16_t irq_reinject_on_ack_count qBroken;
uint32_t irq_coalesced;
uint32_t period;
bool has_coalesced_timer;
QEMUTimer *coalesced_timer qOptional;
Notifier clock_reset_notifier qBroken;
LostTickPolicy lost_tick_policy qImmutable \
qProperty("lost_tick_policy", LOST_TICK_DISCARD);
Notifier suspend_notifier qBroken;
};
c) proposed simplified form:
QIDL_DECLARE(RTCState) {
ISADevice dev q_immutable;
MemoryRegion io q_immutable;
uint8_t cmos_data[128];
uint8_t cmos_index;
int32_t base_year q_property("base_year", 1980);
uint64_t base_rtc;
uint64_t last_update;
int64_t offset;
qemu_irq irq q_immutable;
qemu_irq sqw_irq q_immutable;
int it_shift q_immutable;
/* periodic timer */
QEMUTimer *periodic_timer;
int64_t next_periodic_time;
/* update-ended timer */
QEMUTimer *update_timer;
uint64_t next_alarm_time;
uint16_t irq_reinject_on_ack_count q_broken;
uint32_t irq_coalesced;
uint32_t period;
bool has_coalesced_timer;
QEMUTimer *coalesced_timer q_optional;
Notifier clock_reset_notifier q_broken;
LostTickPolicy lost_tick_policy q_immutable \
q_property("lost_tick_policy", LOST_TICK_DISCARD);
Notifier suspend_notifier q_broken;
Personally, I think b) is the only simplified form that reduces overall visual
noise. So if b) isn't an option, I think a) is the way to go. Using the
lowercasing for qidl(), and lack of an underscore that introduces an extra
break, makes it a lot easier on the eyes, IMO. It's still more keystrokes, but
that's not really my main concern: I just don't want to make all our devices
a headache to look at.
>
> Paolo
>
next prev parent reply other threads:[~2012-09-25 15:45 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 14:07 [Qemu-devel] [PATCH v2] Add infrastructure for QIDL-based device serialization Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 01/22] qapi: qapi-visit.py -> qapi_visit.py so we can import Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 02/22] qapi: qapi-types.py -> qapi_types.py Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 03/22] qapi: qapi-commands.py -> qapi_commands.py Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 04/22] qapi: qapi_visit.py, make code useable as module Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 05/22] qapi: qapi_visit.py, support arrays and complex qapi definitions Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 06/22] qapi: qapi_visit.py, support generating static functions Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 07/22] qapi: qapi_visit.py, support for visiting non-pointer/embedded structs Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 08/22] qapi: add visitor interfaces for C arrays Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 09/22] qapi: QmpOutputVisitor, implement array handling Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 10/22] qapi: QmpInputVisitor, " Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 11/22] qapi: qapi.py, make json parser more robust Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 12/22] qapi: add open-coded visitor for struct tm types Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 13/22] qom-fuse: force single-threaded mode to avoid QMP races Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 14/22] qom-fuse: workaround for truncated properties > 4096 Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 15/22] module additions for schema registration Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 16/22] qdev: move Property-related declarations to qdev-properties.h Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 17/22] qidl: add documentation Michael Roth
2012-09-21 23:16 ` Eric Blake
2012-09-21 14:07 ` [Qemu-devel] [PATCH 18/22] qidl: add lexer library (based on QC parser) Michael Roth
2012-09-21 23:18 ` Eric Blake
2012-09-21 23:52 ` Michael Roth
2012-09-25 21:09 ` Anthony Liguori
2012-09-21 14:07 ` [Qemu-devel] [PATCH 19/22] qidl: add C parser " Michael Roth
2012-09-21 23:19 ` Eric Blake
2012-09-21 14:07 ` [Qemu-devel] [PATCH 20/22] qidl: add QAPI-based code generator Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 21/22] qidl: qidl.h, definitions for qidl annotations Michael Roth
2012-09-21 14:07 ` [Qemu-devel] [PATCH 22/22] qidl: unit tests and build infrastructure Michael Roth
2012-09-21 15:57 ` [Qemu-devel] [PATCH v2] Add infrastructure for QIDL-based device serialization Paolo Bonzini
2012-09-21 16:24 ` Michael Roth
2012-09-22 14:33 ` Blue Swirl
2012-09-24 18:14 ` Michael Roth
2012-09-25 6:37 ` Paolo Bonzini
2012-09-25 15:45 ` Michael Roth [this message]
2012-09-25 21:12 ` Anthony Liguori
2012-09-26 9:57 ` Paolo Bonzini
2012-09-26 10:20 ` Kevin Wolf
2012-09-26 10:33 ` Paolo Bonzini
2012-09-26 15:12 ` Michael Roth
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=20120925154502.GW16157@illuin \
--to=mdroth@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=eblake@redhat.com \
--cc=pbonzini@redhat.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).