Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1201110 > unrolled thread

Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and resulting capabilities in the debug-fs node.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. Greg KH <gregkh@linuxfoundation.org> - 2015-08-05 22:20 +0200
    Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. Philip Moltmann <moltmann@vmware.com> - 2015-08-05 22:30 +0200
      Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com> - 2015-08-05 22:40 +0200
        Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. John Savanyo <jsavanyo@vmware.com> - 2015-08-05 22:50 +0200
          Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2015-08-05 23:00 +0200
            Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. John Savanyo <jsavanyo@vmware.com> - 2015-08-05 23:20 +0200
      Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and  resulting capabilities in the debug-fs node. "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2015-08-05 22:50 +0200

#1201110 — Re: [PATCH v3 5/9] VMware balloon: Show capabilities of balloon and resulting capabilities in the debug-fs node.

On Fri, Jun 12, 2015 at 11:43:26AM -0700, Philip P. Moltmann wrote:
> This helps with debugging vmw_balloon behavior, as it is clear what
> functionality is enabled.
> 
> Acked-by: Andy King <acking@vmware.com>
> Signed-off-by: Xavier Deguillard <xdeguillard@vmware.com>
> ---
>  drivers/misc/vmw_balloon.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> index 72247d9..6eaf7f7 100644
> --- a/drivers/misc/vmw_balloon.c
> +++ b/drivers/misc/vmw_balloon.c
> @@ -46,7 +46,7 @@
>  
>  MODULE_AUTHOR("VMware, Inc.");
>  MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
> -MODULE_VERSION("1.3.2.0-k");
> +MODULE_VERSION("1.3.3.0-k");

This constant change of module version is annoying, is it really even
needed?

I'll take this, but seriously consider just dropping it entirely as it
doesn't mean anything now that the driver is in the kernel tree.

thanks,

greg k-h
--
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/

[toc] | [next] | [standalone]

#1201134

SGksDQoNCj4gPiAgTU9EVUxFX0FVVEhPUigiVk13YXJlLCBJbmMuIik7DQo+ID4gIE1PRFVMRV9E
RVNDUklQVElPTigiVk13YXJlIE1lbW9yeSBDb250cm9sIChCYWxsb29uKSBEcml2ZXIiKTsNCj4g
PiAtTU9EVUxFX1ZFUlNJT04oIjEuMy4yLjAtayIpOw0KPiA+ICtNT0RVTEVfVkVSU0lPTigiMS4z
LjMuMC1rIik7DQo+IA0KPiBUaGlzIGNvbnN0YW50IGNoYW5nZSBvZiBtb2R1bGUgdmVyc2lvbiBp
cyBhbm5veWluZywgaXMgaXQgcmVhbGx5IGV2ZW4NCj4gbmVlZGVkPw0KPiANCj4gSSdsbCB0YWtl
IHRoaXMsIGJ1dCBzZXJpb3VzbHkgY29uc2lkZXIganVzdCBkcm9wcGluZyBpdCBlbnRpcmVseSBh
cyANCj4gaXQNCj4gZG9lc24ndCBtZWFuIGFueXRoaW5nIG5vdyB0aGF0IHRoZSBkcml2ZXIgaXMg
aW4gdGhlIGtlcm5lbCB0cmVlLg0KDQpJIHRoaW5rIHRoaXMgaXMgbWVhbnQgc28gdGhhdCB3ZSBj
YW4gdHJhY2sgd2hpY2ggcGF0Y2hlcyBnb3QgYmFja3BvcnRlZA0KaW50byBSSEVMIGFuZCBTTEVT
Lg0KDQpDQy1pbmcgSm9obiBhcyB0aGUgcG9saWN5IGNvbWVzIGZyb20gaGltLg0KDQpQaGlsaXA=
--
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/

[toc] | [prev] | [next] | [standalone]

#1201136

On Wed, Aug 05, 2015 at 08:22:35PM +0000, Philip Moltmann wrote:
> Hi,
> 
> > >  MODULE_AUTHOR("VMware, Inc.");
> > >  MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
> > > -MODULE_VERSION("1.3.2.0-k");
> > > +MODULE_VERSION("1.3.3.0-k");
> > 
> > This constant change of module version is annoying, is it really even
> > needed?
> > 
> > I'll take this, but seriously consider just dropping it entirely as 
> > it
> > doesn't mean anything now that the driver is in the kernel tree.
> 
> I think this is meant so that we can track which patches got backported
> into RHEL and SLES.

That assumes that RHEL and SLES always take everything that is in
mainline, which I would not count. I.e if you have a security fix and
also change version to 1.3.4.0-k and RedHat picks it up is the driver
that they have really 1.3.4.0-k? If not then what?

You really need to keep track of the substance of the changes needing to
go into each distribution.

Thanks.

-- 
Dmitry
--
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/

[toc] | [prev] | [next] | [standalone]

#1201145

I agree that version number tracking is not perfect. But it is valuable
for us to use as a rough indication that we have attempted to back port
some appropriate subset of patches from mainline to a sustaining distro
release without having to diff the code.

-John

On 8/5/15, 1:33 PM, "dmitry.torokhov@gmail.com"
<dmitry.torokhov@gmail.com> wrote:

>On Wed, Aug 05, 2015 at 08:22:35PM +0000, Philip Moltmann wrote:
>> Hi,
>> 
>> > >  MODULE_AUTHOR("VMware, Inc.");
>> > >  MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
>> > > -MODULE_VERSION("1.3.2.0-k");
>> > > +MODULE_VERSION("1.3.3.0-k");
>> > 
>> > This constant change of module version is annoying, is it really even
>> > needed?
>> > 
>> > I'll take this, but seriously consider just dropping it entirely as
>> > it
>> > doesn't mean anything now that the driver is in the kernel tree.
>> 
>> I think this is meant so that we can track which patches got backported
>> into RHEL and SLES.
>
>That assumes that RHEL and SLES always take everything that is in
>mainline, which I would not count. I.e if you have a security fix and
>also change version to 1.3.4.0-k and RedHat picks it up is the driver
>that they have really 1.3.4.0-k? If not then what?
>
>You really need to keep track of the substance of the changes needing to
>go into each distribution.
>
>Thanks.
>
>-- 
>Dmitry

--
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/

[toc] | [prev] | [next] | [standalone]

#1201148

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Aug 05, 2015 at 08:42:25PM +0000, John Savanyo wrote:
> I agree that version number tracking is not perfect. But it is valuable
> for us to use as a rough indication that we have attempted to back port
> some appropriate subset of patches from mainline to a sustaining distro
> release without having to diff the code.

You have to always diff the code anyway, you can't trust that number,
see my other email as to why.

greg k-h
--
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/

[toc] | [prev] | [next] | [standalone]

#1201153

On 8/5/15, 1:50 PM, "gregkh@linuxfoundation.org"
<gregkh@linuxfoundation.org> wrote:

>You have to always diff the code anyway, you can't trust that number,
>see my other email as to why.
>
>greg k-h

I agree that we need to look at the source code to 100% understand that
status of a driver. However, if VMware has a practice of bumping the
version number for our contributions to help with some of our internal
processes, then I don¹t see any harm in allowing this practice to
continue. We are not asking you personally to interpret these version
numbers in any way. So it should be of little consequence to you to just
accept them as part of our contributions in the future.

Thanks,
John

--
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/

[toc] | [prev] | [next] | [standalone]

#1201146

On Wed, Aug 05, 2015 at 08:22:35PM +0000, Philip Moltmann wrote:
> Hi,
> 
> > >  MODULE_AUTHOR("VMware, Inc.");
> > >  MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
> > > -MODULE_VERSION("1.3.2.0-k");
> > > +MODULE_VERSION("1.3.3.0-k");
> > 
> > This constant change of module version is annoying, is it really even
> > needed?
> > 
> > I'll take this, but seriously consider just dropping it entirely as 
> > it
> > doesn't mean anything now that the driver is in the kernel tree.
> 
> I think this is meant so that we can track which patches got backported
> into RHEL and SLES.

That guarantees all of those patches will conflict and the engineers
will curse your name.  Don't do that, it's horrid.  What happens if
someone picks one patch, and then skips one, and uses the third?  What
would be the "version" then?

Just drop it entirely, it's useless.  You have the source, so you know
what changes are done, no need to try to match it up with a random
number.

greg k-h
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web