Displaying 20 results from an estimated 69 matches for "codingstyle".
2016 Aug 22
5
[PATCH] CodingStyle: add some more error handling guidelines
commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
add some more error handling guidelines") suggests never naming goto
labels after the goto location - that is the error that is handled.
But it's actually pretty common and IMHO it's a reasonable style
provided each error gets its own label, and each label comes after the
matching cl...
2016 Aug 22
5
[PATCH] CodingStyle: add some more error handling guidelines
commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
add some more error handling guidelines") suggests never naming goto
labels after the goto location - that is the error that is handled.
But it's actually pretty common and IMHO it's a reasonable style
provided each error gets its own label, and each label comes after the
matching cl...
2016 Aug 22
0
[PATCH] CodingStyle: add some more error handling guidelines
On Mon, 22 Aug 2016 16:57:46 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> add some more error handling guidelines") suggests never naming goto
> labels after the goto location - that is the error that is handled.
>
> But it's actually pretty common and IMHO it's a reasonable style
> provided each error gets its own label, and each label co...
2016 Aug 23
0
[PATCH] CodingStyle: add some more error handling guidelines
...goto err_bar;
> > ...
> >
> > kfree(foo->bar);
> > err_bar:
> >
> > kfree(foo);
> > err_foo:
> >
> > return ret;
>
>
> I believe the CodingStyle already contain far too much personal style to
> be useful as real style guide. FWIW, I prefer a single error label, at
> the "cost" of additional tests in the error path:
>
>
> foo = kmalloc(SIZE, GFP_KERNEL);
> if (!foo)
>...
2016 Oct 03
1
[PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()
..._map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
> if (err)
> - goto out;
> + goto put_request;
>
> err = blk_execute_rq(vblk->disk->queue, vblk->disk, req, false);
> -out:
> + put_request:
I checked Documentation/CodingStyle and see no reason to rename the label.
It's also not clear why you added a space. The CodingStyle example
does not use a space before the label.
2016 Aug 23
1
[PATCH] CodingStyle: add some more error handling guidelines
...P_KERNEL);
> if (!foo->bar)
> goto err_bar;
> ...
>
> kfree(foo->bar);
> err_bar:
>
> kfree(foo);
> err_foo:
>
> return ret;
I believe the CodingStyle already contain far too much personal style to
be useful as real style guide. FWIW, I prefer a single error label, at
the "cost" of additional tests in the error path:
foo = kmalloc(SIZE, GFP_KERNEL);
if (!foo)
goto err;...
2016 Oct 03
1
[PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()
..._map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
> if (err)
> - goto out;
> + goto put_request;
>
> err = blk_execute_rq(vblk->disk->queue, vblk->disk, req, false);
> -out:
> + put_request:
I checked Documentation/CodingStyle and see no reason to rename the label.
It's also not clear why you added a space. The CodingStyle example
does not use a space before the label.
2016 Aug 22
0
[PATCH] CodingStyle: add some more error handling guidelines
vhost_dev_set_owner() is an example of why come-from labels are
bad style.
devel/drivers/vhost/vhost.c
473 /* Caller should have device mutex */
474 long vhost_dev_set_owner(struct vhost_dev *dev)
475 {
476 struct task_struct *worker;
477 int err;
478
479 /* Is there an owner already? */
480 if (vhost_dev_has_owner(dev)) {
481
2016 Aug 22
0
[PATCH] CodingStyle: add some more error handling guidelines
On Mon, Aug 22, 2016 at 05:53:02PM +0300, Michael S. Tsirkin wrote:
> The point is really naming label for the part of init that failed
> (and so needs to be skipped), rather than the part that will run.
Naming labels after what "needs to be skipped" doesn't work. How does
that meaning make sense for err_cgroup in vhost_dev_set_owner()? What
needs to be skipped here?
2016 Aug 23
0
[PATCH] CodingStyle: add some more error handling guidelines
Lol. The mossy side of a boulder is the alloc, the non-mossy side is
the free!
:P
regards,
dan carpenter
2016 Aug 23
1
[PATCH] CodingStyle: add some more error handling guidelines
Dan Carpenter <dan.carpenter at oracle.com> writes:
> Hike up the mountain, then if you get stuck hike back down using the
> exact same path.
OK, I understand what you say. I just can't resist objecting to that
example ;)
In my experience, finding the exact same path back after hiking up a
mountain is really hard. Especially if you are in enough trouble already
to get stuck. Up
2016 Aug 23
1
[PATCH] CodingStyle: add some more error handling guidelines
Dan Carpenter <dan.carpenter at oracle.com> writes:
> Hike up the mountain, then if you get stuck hike back down using the
> exact same path.
OK, I understand what you say. I just can't resist objecting to that
example ;)
In my experience, finding the exact same path back after hiking up a
mountain is really hard. Especially if you are in enough trouble already
to get stuck. Up
2016 Aug 22
4
[PATCH] CodingStyle: add some more error handling guidelines
On Mon, Aug 22, 2016 at 08:16:17AM -0600, Jonathan Corbet wrote:
> On Mon, 22 Aug 2016 16:57:46 +0300
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
>
> > commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> > add some more error handling guidelines") suggests never naming goto
> > labels after the goto location - that is the error that is handled.
> >
> > But it's actually pretty common and IMHO it's a reasonable style
> > provided each error gets its own...
2016 Aug 22
4
[PATCH] CodingStyle: add some more error handling guidelines
On Mon, Aug 22, 2016 at 08:16:17AM -0600, Jonathan Corbet wrote:
> On Mon, 22 Aug 2016 16:57:46 +0300
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
>
> > commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> > add some more error handling guidelines") suggests never naming goto
> > labels after the goto location - that is the error that is handled.
> >
> > But it's actually pretty common and IMHO it's a reasonable style
> > provided each error gets its own...
2016 Oct 18
2
[PATCH v2 34/37] docs: fix locations of several documents that got moved
...l/kvm/review-checklist.txt | 4 +-
Documentation/vm/numa | 2 +-
.../watchdog/convert_drivers_to_kernel_api.txt | 2 +-
Documentation/watchdog/watchdog-parameters.txt | 2 +-
Documentation/x86/boot.txt | 2 +-
Documentation/zh_CN/CodingStyle | 6 +--
Documentation/zh_CN/HOWTO | 30 ++++++------
Documentation/zh_CN/SecurityBugs | 6 +--
Documentation/zh_CN/SubmittingDrivers | 12 ++---
Documentation/zh_CN/SubmittingPatches | 14 +++---
Documentatio...
2016 Oct 18
2
[PATCH v2 34/37] docs: fix locations of several documents that got moved
...l/kvm/review-checklist.txt | 4 +-
Documentation/vm/numa | 2 +-
.../watchdog/convert_drivers_to_kernel_api.txt | 2 +-
Documentation/watchdog/watchdog-parameters.txt | 2 +-
Documentation/x86/boot.txt | 2 +-
Documentation/zh_CN/CodingStyle | 6 +--
Documentation/zh_CN/HOWTO | 30 ++++++------
Documentation/zh_CN/SecurityBugs | 6 +--
Documentation/zh_CN/SubmittingDrivers | 12 ++---
Documentation/zh_CN/SubmittingPatches | 14 +++---
Documentatio...
2016 Oct 24
0
[PATCH v3 34/37] docs: fix locations of several documents that got moved
...l/kvm/review-checklist.txt | 4 +-
Documentation/vm/numa | 2 +-
.../watchdog/convert_drivers_to_kernel_api.txt | 2 +-
Documentation/watchdog/watchdog-parameters.txt | 2 +-
Documentation/x86/boot.txt | 2 +-
Documentation/zh_CN/CodingStyle | 6 +--
Documentation/zh_CN/HOWTO | 30 ++++++------
Documentation/zh_CN/SecurityBugs | 6 +--
Documentation/zh_CN/SubmittingDrivers | 12 ++---
Documentation/zh_CN/SubmittingPatches | 14 +++---
Documentatio...
2016 Oct 24
0
[PATCH v3 34/37] docs: fix locations of several documents that got moved
...l/kvm/review-checklist.txt | 4 +-
Documentation/vm/numa | 2 +-
.../watchdog/convert_drivers_to_kernel_api.txt | 2 +-
Documentation/watchdog/watchdog-parameters.txt | 2 +-
Documentation/x86/boot.txt | 2 +-
Documentation/zh_CN/CodingStyle | 6 +--
Documentation/zh_CN/HOWTO | 30 ++++++------
Documentation/zh_CN/SecurityBugs | 6 +--
Documentation/zh_CN/SubmittingDrivers | 12 ++---
Documentation/zh_CN/SubmittingPatches | 14 +++---
Documentatio...
2016 Mar 10
1
[RFC -next 2/2] virtio_net: Read and use the advised MTU
...)
> {
> + struct virtnet_info *vi = netdev_priv(dev);
> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
> return -EINVAL;
> + if (vi->negotiated_mtu == true) {
> + pr_warn("changing mtu from negotiated mtu.");
> + }
{} not needed, see Documentation/CodingStyle.
[...]
MBR, Sergei
2016 Mar 10
1
[RFC -next 2/2] virtio_net: Read and use the advised MTU
...)
> {
> + struct virtnet_info *vi = netdev_priv(dev);
> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
> return -EINVAL;
> + if (vi->negotiated_mtu == true) {
> + pr_warn("changing mtu from negotiated mtu.");
> + }
{} not needed, see Documentation/CodingStyle.
[...]
MBR, Sergei