[PATCH] virtio_balloon: coding style fixes

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/uapi/linux/virtio_balloon.h | 3 +--
 drivers/virtio/virtio_balloon.c     | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index be40f70..4b0488f 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h

@@ -36,8 +36,7 @@
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
 
-struct virtio_balloon_config
-{
+struct virtio_balloon_config {
 	/* Number of pages host wants Guest to give up. */
 	__le32 num_pages;
 	/* Number of pages we've actually got in balloon. */

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 3176ea4..0413157 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c

@@ -44,8 +44,7 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
 module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
-struct virtio_balloon
-{
+struct virtio_balloon {
 	struct virtio_device *vdev;
 	struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
 

-- 
MST

On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

I hate to complain but is it really necessary to post such patches to
linux-api?

I thought the list was primarily for API related discussions.
This is not the only mail sent here which doesn't fall into that
category IMO. It is far from low volume list for quite some time.

Please let's get back low volume and API only discussion!

-- 
Michal Hocko
SUSE Labs

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:

On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:

quoted

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

I hate to complain but is it really necessary to post such patches to
linux-api?

Well it's human to err, so it seems wise to copy parties
interested in the ABI/API whenever we are changing files under include/uapi.
Whitespace changes should mostly be safe, but it's not unknown
e.g. to include unrelated changes in the same commit by mistake.

I thought the list was primarily for API related discussions.

Basically this line in MAINTAINERS

ABI/API
L:      linux-api@vger.kernel.org
F:      Documentation/ABI/
F:      include/linux/syscalls.h
F:      include/uapi/
F:      kernel/sys_ni.c

normally means "send all patches affecting files under include/uapi/ to
this list", does it not?

Wasn't this the intent?

This is not the only mail sent here which doesn't fall into that
category IMO. It is far from low volume list for quite some time.

Please let's get back low volume and API only discussion!

Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?

quoted

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/uapi/linux/virtio_balloon.h | 3 +--
 drivers/virtio/virtio_balloon.c     | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index be40f70..4b0488f 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h

@@ -36,8 +36,7 @@
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
 
-struct virtio_balloon_config
-{
+struct virtio_balloon_config {
 	/* Number of pages host wants Guest to give up. */
 	__le32 num_pages;
 	/* Number of pages we've actually got in balloon. */

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 3176ea4..0413157 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c

@@ -44,8 +44,7 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
 module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
-struct virtio_balloon
-{
+struct virtio_balloon {
 	struct virtio_device *vdev;
 	struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
 

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michal Hocko
SUSE Labs

On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:

quoted

On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:

quoted

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

I hate to complain but is it really necessary to post such patches to
linux-api?

Well it's human to err, so it seems wise to copy parties
interested in the ABI/API whenever we are changing files under include/uapi.
Whitespace changes should mostly be safe, but it's not unknown
e.g. to include unrelated changes in the same commit by mistake.

quoted

I thought the list was primarily for API related discussions.

Basically this line in MAINTAINERS

ABI/API
L:      linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
F:      Documentation/ABI/
F:      include/linux/syscalls.h
F:      include/uapi/
F:      kernel/sys_ni.c

normally means "send all patches affecting files under include/uapi/ to
this list", does it not?

Well, this should always be taken as a hint not a hard rule. So if there
is a change which is adding/removing or changing signature then sure but
not everything falls into that category.
 

Wasn't this the intent?

quoted

This is not the only mail sent here which doesn't fall into that
category IMO. It is far from low volume list for quite some time.

Please let's get back low volume and API only discussion!

Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?

This would be an overkill IMO. It would be much more preferable if
people actually think about who from the suggested list (either from
MAINTAINERS or ./scripts/get_maintainer.pl) should be really added.

[...]
-- 
Michal Hocko
SUSE Labs

On Thu, Jan 15, 2015 at 03:13:08PM +0100, Michal Hocko wrote:

On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:

quoted

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:

quoted

On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:

quoted

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

I hate to complain but is it really necessary to post such patches to
linux-api?

Well it's human to err, so it seems wise to copy parties
interested in the ABI/API whenever we are changing files under include/uapi.
Whitespace changes should mostly be safe, but it's not unknown
e.g. to include unrelated changes in the same commit by mistake.

quoted

I thought the list was primarily for API related discussions.

Basically this line in MAINTAINERS

ABI/API
L:      linux-api@vger.kernel.org
F:      Documentation/ABI/
F:      include/linux/syscalls.h
F:      include/uapi/
F:      kernel/sys_ni.c

normally means "send all patches affecting files under include/uapi/ to
this list", does it not?

Well, this should always be taken as a hint not a hard rule. So if there
is a change which is adding/removing or changing signature then sure but
not everything falls into that category.

At least for code I maintain, I really wish people would just Cc me in
any case.  There's been a bunch of cases where people don't Cc me, and
then another maintainer assumes my silence implies agreement, and
applies.  Not nice. OTOH it's easy to ignore an irrelevant patch.

quoted

Wasn't this the intent?

quoted

This is not the only mail sent here which doesn't fall into that
category IMO. It is far from low volume list for quite some time.

Please let's get back low volume and API only discussion!

Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?

This would be an overkill IMO. It would be much more preferable if
people actually think about who from the suggested list (either from
MAINTAINERS or ./scripts/get_maintainer.pl) should be really added.

[...]

Yea, think about it, then what?  I've no idea what is linux-abi for, and
what people subscribed there are interested in. How should I? All I know
is what's in MAINTAINERS, which say "ABI/API". So I copy all ABI/API
patches there.

-- 
Michal Hocko
SUSE Labs
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

On Thu 15-01-15 20:50:18, Michael S. Tsirkin wrote:

On Thu, Jan 15, 2015 at 03:13:08PM +0100, Michal Hocko wrote:

quoted

On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:

[...]

quoted

quoted

Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?

This would be an overkill IMO. It would be much more preferable if
people actually think about who from the suggested list (either from
MAINTAINERS or ./scripts/get_maintainer.pl) should be really added.

[...]

Yea, think about it, then what?  I've no idea what is linux-abi for, and
what people subscribed there are interested in. How should I?

https://www.kernel.org/doc/man-pages/linux-api-ml.html

And by no means, I didn't intend to put critique just to you or only
this particular patch. I just grown frustrated because there are so many
patches which are no longer API/ABI related flying here. This was just
an example.

Hi volume of unrelated emails will turn this into another lkml, I am
afraid.
-- 
Michal Hocko
SUSE Labs

On 01/15/2015 02:44 PM, Michael S. Tsirkin wrote:

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:

quoted

On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:

quoted

Most of our code has
struct foo {
}

Fix two instances where balloon is inconsistent.

I hate to complain but is it really necessary to post such patches to
linux-api?

Well it's human to err, so it seems wise to copy parties
interested in the ABI/API whenever we are changing files under include/uapi.
Whitespace changes should mostly be safe, but it's not unknown
e.g. to include unrelated changes in the same commit by mistake.

quoted

I thought the list was primarily for API related discussions.

Basically this line in MAINTAINERS

ABI/API
L:      linux-api@vger.kernel.org
F:      Documentation/ABI/
F:      include/linux/syscalls.h
F:      include/uapi/
F:      kernel/sys_ni.c

normally means "send all patches affecting files under include/uapi/ to
this list", does it not?

Wasn't this the intent?

quoted

This is not the only mail sent here which doesn't fall into that
category IMO. It is far from low volume list for quite some time.

Please let's get back low volume and API only discussion!

Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?

Well, regardless of what it technically means, there's always going
to be scope for ambiguity, and that's where we differ from computers:
we can ask ourselves the question: will other human beings interested 
in the API/ABI care about this patch?

Thanks,

Michael (also saddened about increasing noise on linux-api)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/