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: > > 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 at 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?> > Signed-off-by: Michael S. Tsirkin <mst at 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 at 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: > > 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? > > 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 at 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.> 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?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: > > 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: > > > > 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 at 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.> > 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? > > 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 at lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Michael Kerrisk (man-pages)
2015-Jan-15 21:09 UTC
[PATCH] virtio_balloon: coding style fixes
On 01/15/2015 02:44 PM, Michael S. Tsirkin wrote:> 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: >>> 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 at 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?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/