* Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
2013-04-10 16:08 [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options K. Y. Srinivasan
@ 2013-04-10 15:49 ` Greg KH
2013-04-10 16:12 ` KY Srinivasan
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2013-04-10 15:49 UTC (permalink / raw)
To: K. Y. Srinivasan; +Cc: linux-kernel, devel, olaf, apw, jasowang
On Wed, Apr 10, 2013 at 09:08:17AM -0700, K. Y. Srinivasan wrote:
> The guest ID captures information about the guest and has room for
> distributions to add distro specific information. Add Kconfig options
> to support distro specific information to be managed easily.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/hv/Kconfig | 14 ++++++++++++++
> drivers/hv/hv.c | 4 +++-
> drivers/hv/hyperv_vmbus.h | 2 +-
> 3 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 0403b51..d2ca9c7 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -19,4 +19,18 @@ config HYPERV_BALLOON
> help
> Select this option to enable Hyper-V Balloon driver.
>
> +config HYPERV_GUEST_D1
> + hex "Distro specific information"
> + range 0x00 0xff
> + default 0
> + help
> + This specifies the Distro vendor
And just what is a distro supposed to set the value here to? For
example, what would Arch Linux pick? Fedora? RHEL? SLES? openSUSE?
You do know that there are more than 0xff different Linux distro
"vendors"? Do they all just get to pick a number that they like?
> +config HYPERV_GUEST_D2
> + hex "Additional Distro specific information"
> + range 0x0000 0xffff
> + default 0
> + help
> + Additional Distro specific kernel version information
Again, what is a distro supposed to do here? What's wrong with the
kernel version information that the kernel already has? Can't you just
use that string?
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
@ 2013-04-10 16:08 K. Y. Srinivasan
2013-04-10 15:49 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: K. Y. Srinivasan @ 2013-04-10 16:08 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, olaf, apw, jasowang; +Cc: K. Y. Srinivasan
The guest ID captures information about the guest and has room for
distributions to add distro specific information. Add Kconfig options
to support distro specific information to be managed easily.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/hv/Kconfig | 14 ++++++++++++++
drivers/hv/hv.c | 4 +++-
drivers/hv/hyperv_vmbus.h | 2 +-
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 0403b51..d2ca9c7 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -19,4 +19,18 @@ config HYPERV_BALLOON
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_GUEST_D1
+ hex "Distro specific information"
+ range 0x00 0xff
+ default 0
+ help
+ This specifies the Distro vendor
+
+config HYPERV_GUEST_D2
+ hex "Additional Distro specific information"
+ range 0x0000 0xffff
+ default 0
+ help
+ Additional Distro specific kernel version information
+
endmenu
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index ae49237..7bd2e88 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -148,7 +148,9 @@ int hv_init(void)
/*
* Write our OS ID.
*/
- hv_context.guestid = generate_guest_id(0, LINUX_VERSION_CODE, 0);
+ hv_context.guestid = generate_guest_id(HYPERV_GUEST_D1,
+ LINUX_VERSION_CODE,
+ HYPERV_GUEST_D2);
wrmsrl(HV_X64_MSR_GUEST_OS_ID, hv_context.guestid);
/* See if the hypercall page is already set */
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 12f2f9e..8c9ebd0 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -410,7 +410,7 @@ enum {
*
* Bit(s)
* 63 - Indicates if the OS is Open Source or not; 1 is Open Source
- * 62:56 - Os Type; Linux is 0x100
+ * 62:56 - Os Type; Linux is 0x1
* 55:48 - Distro specific identification
* 47:16 - Linux kernel version number
* 15:0 - Distro specific identification
--
1.7.4.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* RE: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
2013-04-10 15:49 ` Greg KH
@ 2013-04-10 16:12 ` KY Srinivasan
2013-04-10 16:33 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: KY Srinivasan @ 2013-04-10 16:12 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Wednesday, April 10, 2013 11:50 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig
> options
>
> On Wed, Apr 10, 2013 at 09:08:17AM -0700, K. Y. Srinivasan wrote:
> > The guest ID captures information about the guest and has room for
> > distributions to add distro specific information. Add Kconfig options
> > to support distro specific information to be managed easily.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/hv/Kconfig | 14 ++++++++++++++
> > drivers/hv/hv.c | 4 +++-
> > drivers/hv/hyperv_vmbus.h | 2 +-
> > 3 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> > index 0403b51..d2ca9c7 100644
> > --- a/drivers/hv/Kconfig
> > +++ b/drivers/hv/Kconfig
> > @@ -19,4 +19,18 @@ config HYPERV_BALLOON
> > help
> > Select this option to enable Hyper-V Balloon driver.
> >
> > +config HYPERV_GUEST_D1
> > + hex "Distro specific information"
> > + range 0x00 0xff
> > + default 0
> > + help
> > + This specifies the Distro vendor
>
> And just what is a distro supposed to set the value here to? For
> example, what would Arch Linux pick? Fedora? RHEL? SLES? openSUSE?
> You do know that there are more than 0xff different Linux distro
> "vendors"? Do they all just get to pick a number that they like?
MSFT is planning to manage this space; we will assign distributions unique numbers
that they can use here.
>
> > +config HYPERV_GUEST_D2
> > + hex "Additional Distro specific information"
> > + range 0x0000 0xffff
> > + default 0
> > + help
> > + Additional Distro specific kernel version information
>
> Again, what is a distro supposed to do here? What's wrong with the
> kernel version information that the kernel already has? Can't you just
> use that string?
We already have the kernel version information. Distros can choose to use this
as they please. We are recommending that they use this field to track some distro specific
build number.
Regards,
K. Y
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
2013-04-10 16:12 ` KY Srinivasan
@ 2013-04-10 16:33 ` Greg KH
2013-04-10 17:37 ` KY Srinivasan
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2013-04-10 16:33 UTC (permalink / raw)
To: KY Srinivasan
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com
On Wed, Apr 10, 2013 at 04:12:24PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Wednesday, April 10, 2013 11:50 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> > apw@canonical.com; jasowang@redhat.com
> > Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig
> > options
> >
> > On Wed, Apr 10, 2013 at 09:08:17AM -0700, K. Y. Srinivasan wrote:
> > > The guest ID captures information about the guest and has room for
> > > distributions to add distro specific information. Add Kconfig options
> > > to support distro specific information to be managed easily.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > > drivers/hv/Kconfig | 14 ++++++++++++++
> > > drivers/hv/hv.c | 4 +++-
> > > drivers/hv/hyperv_vmbus.h | 2 +-
> > > 3 files changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> > > index 0403b51..d2ca9c7 100644
> > > --- a/drivers/hv/Kconfig
> > > +++ b/drivers/hv/Kconfig
> > > @@ -19,4 +19,18 @@ config HYPERV_BALLOON
> > > help
> > > Select this option to enable Hyper-V Balloon driver.
> > >
> > > +config HYPERV_GUEST_D1
> > > + hex "Distro specific information"
> > > + range 0x00 0xff
> > > + default 0
> > > + help
> > > + This specifies the Distro vendor
> >
> > And just what is a distro supposed to set the value here to? For
> > example, what would Arch Linux pick? Fedora? RHEL? SLES? openSUSE?
> > You do know that there are more than 0xff different Linux distro
> > "vendors"? Do they all just get to pick a number that they like?
>
> MSFT is planning to manage this space; we will assign distributions
> unique numbers that they can use here.
And how will that happen? A single line in a Kconfig file doesn't cut
it, sorry.
What's wrong with lanana.org managing it instead? That's who manages
all of the rest of the kernel-limited resources.
And what happens when you have more than 256? We already know that's
not going to be enough numbers, why start out already with an obsolete
range?
> > > +config HYPERV_GUEST_D2
> > > + hex "Additional Distro specific information"
> > > + range 0x0000 0xffff
> > > + default 0
> > > + help
> > > + Additional Distro specific kernel version information
> >
> > Again, what is a distro supposed to do here? What's wrong with the
> > kernel version information that the kernel already has? Can't you just
> > use that string?
>
> We already have the kernel version information. Distros can choose to
> use this as they please. We are recommending that they use this field
> to track some distro specific build number.
That's in the kernel version already, why put it here again?
Again, you need _way_ more than just a single Kconfig line for new
configuration options where you expect distros to set a value to a
unique thing,
And lastly, you do know about /etc/os-release, the cross-distro,
standardized way to specify distro version and build information,
right? Why aren't you just using that instead of creating your own
"unique" way of defining the exact same thing?
Don't create a new standard just when we all finally picked one to
follow, it makes it look like you don't think what the community decided
on is valid, which isn't a wise decision.
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
2013-04-10 16:33 ` Greg KH
@ 2013-04-10 17:37 ` KY Srinivasan
2013-04-10 17:50 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: KY Srinivasan @ 2013-04-10 17:37 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Wednesday, April 10, 2013 12:34 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig
> options
>
> On Wed, Apr 10, 2013 at 04:12:24PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Wednesday, April 10, 2013 11:50 AM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> olaf@aepfle.de;
> > > apw@canonical.com; jasowang@redhat.com
> > > Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific
> Kconfig
> > > options
> > >
> > > On Wed, Apr 10, 2013 at 09:08:17AM -0700, K. Y. Srinivasan wrote:
> > > > The guest ID captures information about the guest and has room for
> > > > distributions to add distro specific information. Add Kconfig options
> > > > to support distro specific information to be managed easily.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > > drivers/hv/Kconfig | 14 ++++++++++++++
> > > > drivers/hv/hv.c | 4 +++-
> > > > drivers/hv/hyperv_vmbus.h | 2 +-
> > > > 3 files changed, 18 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> > > > index 0403b51..d2ca9c7 100644
> > > > --- a/drivers/hv/Kconfig
> > > > +++ b/drivers/hv/Kconfig
> > > > @@ -19,4 +19,18 @@ config HYPERV_BALLOON
> > > > help
> > > > Select this option to enable Hyper-V Balloon driver.
> > > >
> > > > +config HYPERV_GUEST_D1
> > > > + hex "Distro specific information"
> > > > + range 0x00 0xff
> > > > + default 0
> > > > + help
> > > > + This specifies the Distro vendor
> > >
> > > And just what is a distro supposed to set the value here to? For
> > > example, what would Arch Linux pick? Fedora? RHEL? SLES? openSUSE?
> > > You do know that there are more than 0xff different Linux distro
> > > "vendors"? Do they all just get to pick a number that they like?
> >
> > MSFT is planning to manage this space; we will assign distributions
> > unique numbers that they can use here.
>
> And how will that happen? A single line in a Kconfig file doesn't cut
> it, sorry.
>
> What's wrong with lanana.org managing it instead? That's who manages
> all of the rest of the kernel-limited resources.
>
> And what happens when you have more than 256? We already know that's
> not going to be enough numbers, why start out already with an obsolete
> range?
Greg,
You are reading more into this than there is. As it stands now (without this patch), the code
that constructs the guest OS ID has place holders for adding in some distro specific tags into
this ID. Look at the function generate_guest_id() in hyperv_vmbus.h. Currently these values are
hard-coded to 0. All I am doing here is to present a more maintainable way of customizing these.
The default values for these are currently 0 and even with this patch, the default values will continue
to be 0. However, if a distro chooses to modify these defaults, with this patch they can do so in a more
maintainable way - they could set this config parameter on a per-tree basis.
This information will potentially be used to automate the support infrastructure. We feel that with 24 bits
between the two distro specific tags, we have enough bits to differentiate the distros that may run on
our platform.
>
> > > > +config HYPERV_GUEST_D2
> > > > + hex "Additional Distro specific information"
> > > > + range 0x0000 0xffff
> > > > + default 0
> > > > + help
> > > > + Additional Distro specific kernel version information
> > >
> > > Again, what is a distro supposed to do here? What's wrong with the
> > > kernel version information that the kernel already has? Can't you just
> > > use that string?
> >
> > We already have the kernel version information. Distros can choose to
> > use this as they please. We are recommending that they use this field
> > to track some distro specific build number.
>
> That's in the kernel version already, why put it here again?
>
> Again, you need _way_ more than just a single Kconfig line for new
> configuration options where you expect distros to set a value to a
> unique thing,
>
> And lastly, you do know about /etc/os-release, the cross-distro,
> standardized way to specify distro version and build information,
> right? Why aren't you just using that instead of creating your own
> "unique" way of defining the exact same thing?
>
> Don't create a new standard just when we all finally picked one to
> follow, it makes it look like you don't think what the community decided
> on is valid, which isn't a wise decision.
As I said, we are not proposing any new standard here. KVP currently retrieves info
from /etc/os-release. The tooling on the Windows host uses the guest OS ID MSR to identify guest
operating systems running on the host . With what we currently have, we can detect that it is Linux based
on the information we use to construct the OS ID. This information also includes the kernel version number
as well. This patch merely makes it easy to add distro specific tags. It is entirely up to distros to decide if they want to
add these tags. The default values are 0 for both these fields and they continue to be 0.
Regards,
K. Y
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options
2013-04-10 17:37 ` KY Srinivasan
@ 2013-04-10 17:50 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2013-04-10 17:50 UTC (permalink / raw)
To: KY Srinivasan
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com
On Wed, Apr 10, 2013 at 05:37:41PM +0000, KY Srinivasan wrote:
> You are reading more into this than there is. As it stands now
> (without this patch), the code that constructs the guest OS ID has
> place holders for adding in some distro specific tags into this ID.
I understand that, the fact that you now want this to be a configurable
value at build time, yet provide exactly NO information to anyone as to
what to set the values to, what the values mean, or anything else about
these values this is why I am rejecting this patch.
If you are already properly handling os-release, then there is no need
for these values to mean anything for a Linux guest, as it would be
totally redundant, and probably wrong (hint, the same kernel binary can
be running on different os userspace layers.)
sorry,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-10 17:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-10 16:08 [PATCH 1/1] Drivers: hv: vmbus: Add additional distro specific Kconfig options K. Y. Srinivasan
2013-04-10 15:49 ` Greg KH
2013-04-10 16:12 ` KY Srinivasan
2013-04-10 16:33 ` Greg KH
2013-04-10 17:37 ` KY Srinivasan
2013-04-10 17:50 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox