From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gregory Haskins <ghaskins@novell.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, avi@redhat.com
Subject: Re: [KVM PATCH v9 1/2] KVM: make io_bus interface more robust
Date: Wed, 8 Jul 2009 10:47:42 +0300 [thread overview]
Message-ID: <20090708074742.GA10803@redhat.com> (raw)
In-Reply-To: <4A538533.3030703@novell.com>
On Tue, Jul 07, 2009 at 01:26:11PM -0400, Gregory Haskins wrote:
> These patches pass checkpatch.pl and I happen to like the extra
> whitespace for readability. I agree that a random isolated whitespace
> hunk, or double whitespace in a row are probably inadvertent and should
> be pointed out. But these little one liners in the middle of code I
> generally do on purpose (for instance, [A]).
Where it's on purpose, it's on purpose. I am just trying to convey a
rather obvious point that each line of code should have a purpose in
life, and that includes empty lines :)
> I suppose its personal preference either way, so I guess unless Avi
> objects lets just each have our own style in that regard.
I think Avi already said we don't need to standardize everything.
I hope at least some of the comments were helpful.
> >> @@ -552,6 +554,11 @@ struct kvm_pic *kvm_create_pic(struct kvm *kvm)
> >> * Initialize PIO device
> >> */
> >> kvm_iodevice_init(&s->dev, &picdev_ops);
> >> - kvm_io_bus_register_dev(kvm, &kvm->pio_bus, &s->dev);
> >> + ret = kvm_io_bus_register_dev(kvm, &kvm->pio_bus, &s->dev);
> >> + if (ret < 0) {
> >>
> >
> > I thought the function returns 0 on success?
> > If so can we just if (ret) all over?
> >
> >
>
> I guess, but what does that churn buy us?
It's not that important really. I think we need to document the return
value, and check it according to how it is documented. The reason I
commented, I see < 0 and ask "what if it is > 0"? I look it up and it
turns out it's never > 0. So why check < 0?
> >> + ret = kvm_io_bus_register_dev(kvm, &kvm->mmio_bus, &dev->dev);
> >> + if (ret < 0)
> >> + kfree(dev);
> >> +
> >>
> >
> > kill empty line
> >
>
> Why do you object here especially when there is precedence
How do you mean, precedence?
> with
> something like the space before the return with [B]? I think big
> mono-blocks of code are ugly and harder to read, personally.
I don't intend to keep arguing and I agree it's a question of style.
But since you ask why I'll try to answer. I think an
empty line should help delimit a block of code with some common meaning,
like a paragraph. But if overused it loses meaning and stops being
helpful.
E.g., it does not make sense to put it between every 2 lines of code in a
function. It also does not make sense to put it after } which is
already delimiting a block in a visible way; it does not make sense to
put it around a multiline comment which is delimited by /**/. It does
not make sense to put it around an idented block which is already
delimited by indentation.
> >> + if (bus->devs[i] == dev) {
> >> + bus->devs[i] = bus->devs[--bus->dev_count];
> >> + break;
> >> + }
> >> + }
> >>
> >
> > no {} around single statement
This is actually part of style IMO, it is just hard for a perl script to
catch :).
> >
> >
> >> }
> >>
> >> static struct notifier_block kvm_cpu_notifier = {
> >>
>
>
next prev parent reply other threads:[~2009-07-08 7:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-06 20:33 [KVM PATCH v9 0/2] iosignalfd Gregory Haskins
2009-07-06 20:33 ` [KVM PATCH v9 1/2] KVM: make io_bus interface more robust Gregory Haskins
2009-07-07 11:20 ` Michael S. Tsirkin
2009-07-07 17:26 ` Gregory Haskins
2009-07-08 7:47 ` Michael S. Tsirkin [this message]
2009-07-08 11:40 ` Gregory Haskins
2009-07-06 20:33 ` [KVM PATCH v9 2/2] KVM: add iosignalfd support Gregory Haskins
2009-07-07 11:20 ` Michael S. Tsirkin
2009-07-07 11:53 ` Avi Kivity
2009-07-07 12:22 ` Michael S. Tsirkin
2009-07-07 12:27 ` Avi Kivity
2009-07-07 12:51 ` Michael S. Tsirkin
2009-07-07 12:56 ` Gregory Haskins
2009-07-07 13:21 ` Michael S. Tsirkin
2009-07-07 13:30 ` Gregory Haskins
2009-07-07 12:56 ` Avi Kivity
2009-07-07 13:17 ` Gregory Haskins
2009-07-07 12:15 ` Gregory Haskins
2009-07-07 12:48 ` Michael S. Tsirkin
2009-07-07 12:56 ` Avi Kivity
2009-07-07 12:58 ` Michael S. Tsirkin
2009-07-07 13:16 ` Gregory Haskins
2009-07-07 9:22 ` [KVM PATCH v9 0/2] iosignalfd Avi Kivity
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=20090708074742.GA10803@redhat.com \
--to=mst@redhat.com \
--cc=avi@redhat.com \
--cc=ghaskins@novell.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.