* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Greg KH @ 2011-05-04 19:58 UTC (permalink / raw)
To: KY Srinivasan
Cc: Randy Dunlap, virtualization@lists.osdl.org,
devel@linuxdriverproject.org, H Hartley Sweeten, Haiyang Zhang,
linux-kernel@vger.kernel.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DFE61@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Wed, May 04, 2011 at 07:54:09PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: devel-bounces@linuxdriverproject.org [mailto:devel-
> > bounces@linuxdriverproject.org] On Behalf Of Greg KH
> > Sent: Wednesday, May 04, 2011 3:40 PM
> > To: Randy Dunlap
> > Cc: virtualization@lists.osdl.org; devel@linuxdriverproject.org; H Hartley
> > Sweeten; Haiyang Zhang; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv
> > Kconfig
> >
> > On Wed, May 04, 2011 at 12:33:02PM -0700, Randy Dunlap wrote:
> > > On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
> > >
> > > > On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> > > > > On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> > > > > >
> > > > > > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > > > > > Kconfig to reflect this.
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > > > > ---
> > > > > > drivers/staging/hv/Kconfig | 2 +-
> > > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > > > > > index 76f0756..5e0c9f6 100644
> > > > > > --- a/drivers/staging/hv/Kconfig
> > > > > > +++ b/drivers/staging/hv/Kconfig
> > > > > > @@ -1,6 +1,6 @@
> > > > > > config HYPERV
> > > > > > tristate "Microsoft Hyper-V client drivers"
> > > > > > - depends on X86 && m
> > > > > > + depends on X86 && ACPI && PCI && m
> > > > > > default n
> > > > > > help
> > > > > > Select this option to run Linux as a Hyper-V client operating
> > > > >
> > > > > ACPI itself depends on PCI.
> > > >
> > > > Still? I thought that got removed a while ago.
> > >
> > > Still. Len has written in the past that technically there is no such
> > > dependency, but in reality there is, for now at least. IIRC.
> >
> > Ok, but then we should still say we depend on PCI to handle if/when ACPI
> > removes that dependancy in the future. It doesn't hurt here at all.
>
> Greg,
> I have sent you both versions of this patch; one with explicit dependency on PCI and
> one with implicit dependency on PCI; you decide.
Thanks, I'll pick one :)
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Randy Dunlap @ 2011-05-04 19:55 UTC (permalink / raw)
To: Greg KH
Cc: H Hartley Sweeten, devel@linuxdriverproject.org, Haiyang Zhang,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <20110504193954.GA30937@suse.de>
On Wed, 4 May 2011 12:39:54 -0700 Greg KH wrote:
> On Wed, May 04, 2011 at 12:33:02PM -0700, Randy Dunlap wrote:
> > On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
> >
> > > On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> > > > On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> > > > >
> > > > > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > > > > Kconfig to reflect this.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > > > ---
> > > > > drivers/staging/hv/Kconfig | 2 +-
> > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > > > > index 76f0756..5e0c9f6 100644
> > > > > --- a/drivers/staging/hv/Kconfig
> > > > > +++ b/drivers/staging/hv/Kconfig
> > > > > @@ -1,6 +1,6 @@
> > > > > config HYPERV
> > > > > tristate "Microsoft Hyper-V client drivers"
> > > > > - depends on X86 && m
> > > > > + depends on X86 && ACPI && PCI && m
> > > > > default n
> > > > > help
> > > > > Select this option to run Linux as a Hyper-V client operating
> > > >
> > > > ACPI itself depends on PCI.
> > >
> > > Still? I thought that got removed a while ago.
> >
> > Still. Len has written in the past that technically there is no such
> > dependency, but in reality there is, for now at least. IIRC.
>
> Ok, but then we should still say we depend on PCI to handle if/when ACPI
> removes that dependancy in the future. It doesn't hurt here at all.
Yes, I prefer that also.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: KY Srinivasan @ 2011-05-04 19:54 UTC (permalink / raw)
To: Greg KH, Randy Dunlap
Cc: virtualization@lists.osdl.org, devel@linuxdriverproject.org,
H Hartley Sweeten, Haiyang Zhang, linux-kernel@vger.kernel.org
In-Reply-To: <20110504193954.GA30937@suse.de>
> -----Original Message-----
> From: devel-bounces@linuxdriverproject.org [mailto:devel-
> bounces@linuxdriverproject.org] On Behalf Of Greg KH
> Sent: Wednesday, May 04, 2011 3:40 PM
> To: Randy Dunlap
> Cc: virtualization@lists.osdl.org; devel@linuxdriverproject.org; H Hartley
> Sweeten; Haiyang Zhang; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv
> Kconfig
>
> On Wed, May 04, 2011 at 12:33:02PM -0700, Randy Dunlap wrote:
> > On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
> >
> > > On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> > > > On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> > > > >
> > > > > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > > > > Kconfig to reflect this.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > > > ---
> > > > > drivers/staging/hv/Kconfig | 2 +-
> > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > > > > index 76f0756..5e0c9f6 100644
> > > > > --- a/drivers/staging/hv/Kconfig
> > > > > +++ b/drivers/staging/hv/Kconfig
> > > > > @@ -1,6 +1,6 @@
> > > > > config HYPERV
> > > > > tristate "Microsoft Hyper-V client drivers"
> > > > > - depends on X86 && m
> > > > > + depends on X86 && ACPI && PCI && m
> > > > > default n
> > > > > help
> > > > > Select this option to run Linux as a Hyper-V client operating
> > > >
> > > > ACPI itself depends on PCI.
> > >
> > > Still? I thought that got removed a while ago.
> >
> > Still. Len has written in the past that technically there is no such
> > dependency, but in reality there is, for now at least. IIRC.
>
> Ok, but then we should still say we depend on PCI to handle if/when ACPI
> removes that dependancy in the future. It doesn't hurt here at all.
Greg,
I have sent you both versions of this patch; one with explicit dependency on PCI and
one with implicit dependency on PCI; you decide.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Greg KH @ 2011-05-04 19:39 UTC (permalink / raw)
To: Randy Dunlap
Cc: H Hartley Sweeten, devel@linuxdriverproject.org, Haiyang Zhang,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <20110504123302.1ef22682.rdunlap@xenotime.net>
On Wed, May 04, 2011 at 12:33:02PM -0700, Randy Dunlap wrote:
> On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
>
> > On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> > > On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> > > >
> > > > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > > > Kconfig to reflect this.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > > ---
> > > > drivers/staging/hv/Kconfig | 2 +-
> > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > > > index 76f0756..5e0c9f6 100644
> > > > --- a/drivers/staging/hv/Kconfig
> > > > +++ b/drivers/staging/hv/Kconfig
> > > > @@ -1,6 +1,6 @@
> > > > config HYPERV
> > > > tristate "Microsoft Hyper-V client drivers"
> > > > - depends on X86 && m
> > > > + depends on X86 && ACPI && PCI && m
> > > > default n
> > > > help
> > > > Select this option to run Linux as a Hyper-V client operating
> > >
> > > ACPI itself depends on PCI.
> >
> > Still? I thought that got removed a while ago.
>
> Still. Len has written in the past that technically there is no such
> dependency, but in reality there is, for now at least. IIRC.
Ok, but then we should still say we depend on PCI to handle if/when ACPI
removes that dependancy in the future. It doesn't hurt here at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Randy Dunlap @ 2011-05-04 19:33 UTC (permalink / raw)
To: Greg KH
Cc: virtualization@lists.osdl.org, devel@linuxdriverproject.org,
H Hartley Sweeten, Haiyang Zhang, linux-kernel@vger.kernel.org
In-Reply-To: <20110504185338.GB9823@suse.de>
On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
> On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> > On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> > >
> > > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > > Kconfig to reflect this.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > ---
> > > drivers/staging/hv/Kconfig | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > > index 76f0756..5e0c9f6 100644
> > > --- a/drivers/staging/hv/Kconfig
> > > +++ b/drivers/staging/hv/Kconfig
> > > @@ -1,6 +1,6 @@
> > > config HYPERV
> > > tristate "Microsoft Hyper-V client drivers"
> > > - depends on X86 && m
> > > + depends on X86 && ACPI && PCI && m
> > > default n
> > > help
> > > Select this option to run Linux as a Hyper-V client operating
> >
> > ACPI itself depends on PCI.
>
> Still? I thought that got removed a while ago.
Still. Len has written in the past that technically there is no such
dependency, but in reality there is, for now at least. IIRC.
> > It also depends on IA64 || X86. Will the vmbus driver work with IA64?
>
> No.
>
> > If so the depends on could just be:
> >
> > depends on ACPI && m
>
> No, see above for the IA64 reason.
>
> > Also, default n is redudant since n is the default anyway.
>
> True, but it doesn't hurt either :)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: K. Y. Srinivasan @ 2011-05-04 19:19 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang
The vmbus driver dependes on ACPI and PCI subsystems. Change
Kconfig to reflect this.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/staging/hv/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
index 76f0756..d8c119c 100644
--- a/drivers/staging/hv/Kconfig
+++ b/drivers/staging/hv/Kconfig
@@ -1,6 +1,6 @@
config HYPERV
tristate "Microsoft Hyper-V client drivers"
- depends on X86 && m
+ depends on X86 && ACPI && m
default n
help
Select this option to run Linux as a Hyper-V client operating
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Greg KH @ 2011-05-04 18:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization,
Haiyang Zhang
In-Reply-To: <20110504185142.GA28458@infradead.org>
On Wed, May 04, 2011 at 02:51:42PM -0400, Christoph Hellwig wrote:
> On Wed, May 04, 2011 at 11:51:45AM -0700, K. Y. Srinivasan wrote:
> > config HYPERV
> > tristate "Microsoft Hyper-V client drivers"
> > - depends on X86 && m
> > + depends on X86 && ACPI && PCI && m
>
> I can't see anything preventing this driver from beeing built-in,
> so the "depends on m" should probably go away.
Originally there were some problems with some bad global symbols.
Hopefully those should all be resolved now, but it can't hurt to review
the code to verify this first.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Greg KH @ 2011-05-04 18:53 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: devel@linuxdriverproject.org, Haiyang Zhang,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <0D753D10438DA54287A00B027084269764D295CE91@AUSP01VMBX24.collaborationhost.net>
On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
> On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> >
> > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > Kconfig to reflect this.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/staging/hv/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > index 76f0756..5e0c9f6 100644
> > --- a/drivers/staging/hv/Kconfig
> > +++ b/drivers/staging/hv/Kconfig
> > @@ -1,6 +1,6 @@
> > config HYPERV
> > tristate "Microsoft Hyper-V client drivers"
> > - depends on X86 && m
> > + depends on X86 && ACPI && PCI && m
> > default n
> > help
> > Select this option to run Linux as a Hyper-V client operating
>
> ACPI itself depends on PCI.
Still? I thought that got removed a while ago.
> It also depends on IA64 || X86. Will the vmbus driver work with IA64?
No.
> If so the depends on could just be:
>
> depends on ACPI && m
No, see above for the IA64 reason.
> Also, default n is redudant since n is the default anyway.
True, but it doesn't hurt either :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: K. Y. Srinivasan @ 2011-05-04 18:51 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang
The vmbus driver dependes on ACPI and PCI subsystems. Change
Kconfig to reflect this.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/staging/hv/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
index 76f0756..5e0c9f6 100644
--- a/drivers/staging/hv/Kconfig
+++ b/drivers/staging/hv/Kconfig
@@ -1,6 +1,6 @@
config HYPERV
tristate "Microsoft Hyper-V client drivers"
- depends on X86 && m
+ depends on X86 && ACPI && PCI && m
default n
help
Select this option to run Linux as a Hyper-V client operating
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: Christoph Hellwig @ 2011-05-04 18:51 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, Haiyang Zhang
In-Reply-To: <1304535105-26892-1-git-send-email-kys@microsoft.com>
On Wed, May 04, 2011 at 11:51:45AM -0700, K. Y. Srinivasan wrote:
> config HYPERV
> tristate "Microsoft Hyper-V client drivers"
> - depends on X86 && m
> + depends on X86 && ACPI && PCI && m
I can't see anything preventing this driver from beeing built-in,
so the "depends on m" should probably go away.
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: KY Srinivasan @ 2011-05-04 18:48 UTC (permalink / raw)
To: H Hartley Sweeten, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel
Cc: Haiyang Zhang
In-Reply-To: <0D753D10438DA54287A00B027084269764D295CE91@AUSP01VMBX24.collaborationhost.net>
> -----Original Message-----
> From: H Hartley Sweeten [mailto:hartleys@visionengravers.com]
> Sent: Wednesday, May 04, 2011 2:44 PM
> To: KY Srinivasan; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Cc: Haiyang Zhang
> Subject: RE: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv
> Kconfig
>
> On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
> >
> > The vmbus driver dependes on ACPI and PCI subsystems. Change
> > Kconfig to reflect this.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/staging/hv/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> > index 76f0756..5e0c9f6 100644
> > --- a/drivers/staging/hv/Kconfig
> > +++ b/drivers/staging/hv/Kconfig
> > @@ -1,6 +1,6 @@
> > config HYPERV
> > tristate "Microsoft Hyper-V client drivers"
> > - depends on X86 && m
> > + depends on X86 && ACPI && PCI && m
> > default n
> > help
> > Select this option to run Linux as a Hyper-V client operating
>
> ACPI itself depends on PCI. It also depends on IA64 || X86. Will the
> vmbus driver work with IA64? If so the depends on could just be:
>
> depends on ACPI && m
Good point; vmbus will not work on IA64 though. So, minimally we would want
X86 && ACPI. I will resend this with this change.
Regards,
K. Y
>
> Also, default n is redudant since n is the default anyway.
>
> Regards,
> Hartley
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig
From: H Hartley Sweeten @ 2011-05-04 18:44 UTC (permalink / raw)
To: K. Y. Srinivasan, gregkh@suse.de, linux-kernel@vger.kernel.org
Cc: Haiyang Zhang
In-Reply-To: <1304535105-26892-1-git-send-email-kys@microsoft.com>
On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
>
> The vmbus driver dependes on ACPI and PCI subsystems. Change
> Kconfig to reflect this.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/staging/hv/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
> index 76f0756..5e0c9f6 100644
> --- a/drivers/staging/hv/Kconfig
> +++ b/drivers/staging/hv/Kconfig
> @@ -1,6 +1,6 @@
> config HYPERV
> tristate "Microsoft Hyper-V client drivers"
> - depends on X86 && m
> + depends on X86 && ACPI && PCI && m
> default n
> help
> Select this option to run Linux as a Hyper-V client operating
ACPI itself depends on PCI. It also depends on IA64 || X86. Will the
vmbus driver work with IA64? If so the depends on could just be:
depends on ACPI && m
Also, default n is redudant since n is the default anyway.
Regards,
Hartley
^ permalink raw reply
* Re: various vmbus review comments
From: Greg KH @ 2011-05-04 18:28 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DFD6B@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Wed, May 04, 2011 at 04:58:39PM +0000, KY Srinivasan wrote:
> > > 2) hyperv_storage.h - this has all the definitions needed to build storage
> > > drivers for Hyper-V. Storage drivers will include hyperv.h and
> > > hyperv_storage.h.
> > >
> > > 3) hyperv_net.h - this has all the definitions needed to build the network
> > > driver for Hyper-V. The netvsc driver will include hyperv.h and hyperv_net.h.
> > >
> > > 4) hyperv_utils.h - this has all the definitions needed to build the util driver.
> > > The util driver would include hyperv.h and hyperv_utils.h.
> >
> > No for all 3 of these. Why would a simple driver need a .h file at all?
> > Just include the structures within the .c file, making it nice and
> > self-contained. There's no need to clutter things up, and individual
> > driver .h files should _never_ be in include/linux.
>
> Agreed - we don't need to clutter up include/linux directory with individual
> driver.h files. However, including all the definitions in the .c file would also be
> ugly. For instance there are multiple *.c files for the storage drivers and we don't
> want to replicate the contents of hyperv_storage.h in each of these .c files.
> The same is true for the netvsc driver - there are multiple .c files where we would need
> to replicate the contents of hyperv_net.h.
>
> How about I keep these driver specific header files; but these could be local to the
> directory where these drivers land.
Yes, that is fine. I still find it odd that you need multiple files for
the network driver. We have much more complex and longer drivers for
common cards these days than this one, all in one file. But that's for
you and the network developers to argue over :)
thanks,
greg k-h
^ permalink raw reply
* RE: various vmbus review comments
From: KY Srinivasan @ 2011-05-04 16:58 UTC (permalink / raw)
To: Greg KH
Cc: devel@linuxdriverproject.org, gregkh@suse.de,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <20110504163228.GA19754@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, May 04, 2011 12:32 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: various vmbus review comments
>
> On Wed, May 04, 2011 at 04:20:11PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Sent: Tuesday, May 03, 2011 4:47 PM
> > > To: KY Srinivasan
> > > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > > Subject: various vmbus review comments
> > >
> > > I just took a quick look at the vmbus code, and have the following
> >
> > I have currently consolidated all the header files as follows:
> >
> > 1) hyperv.h - this will have all the vmbus related definitions
> > needed to build drivers that attach to the bus (as you have suggested).
>
> Great.
>
> > 2) hyperv_storage.h - this has all the definitions needed to build storage
> > drivers for Hyper-V. Storage drivers will include hyperv.h and
> > hyperv_storage.h.
> >
> > 3) hyperv_net.h - this has all the definitions needed to build the network
> > driver for Hyper-V. The netvsc driver will include hyperv.h and hyperv_net.h.
> >
> > 4) hyperv_utils.h - this has all the definitions needed to build the util driver.
> > The util driver would include hyperv.h and hyperv_utils.h.
>
> No for all 3 of these. Why would a simple driver need a .h file at all?
> Just include the structures within the .c file, making it nice and
> self-contained. There's no need to clutter things up, and individual
> driver .h files should _never_ be in include/linux.
Agreed - we don't need to clutter up include/linux directory with individual
driver.h files. However, including all the definitions in the .c file would also be
ugly. For instance there are multiple *.c files for the storage drivers and we don't
want to replicate the contents of hyperv_storage.h in each of these .c files.
The same is true for the netvsc driver - there are multiple .c files where we would need
to replicate the contents of hyperv_net.h.
How about I keep these driver specific header files; but these could be local to the
directory where these drivers land.
> >
> > > - the instances of hv_driver structures need to be static and
> > > not programatically defined, like all other USB and PCI
> > > drivers are handled.
> > > - module reference counting. Are you sure you got it all right
> > > for the individual modules that attach to the bus? I don't
> > > see any reference counting happening, is that correct?
> >
> > For this round, I want to concentrate on just the vmbus driver. So,
> > module reference counting is I don't think an issue for the vmbus driver
> > given that the driver is not unlodable. Once I am done with the vmbus driver
> > I will address the module reference counting issues for other drivers.
>
> No, I am referring to the module reference counting of the bus drivers
> that register with the vmbus core. You aren't doing that at all, and
> you probably need to make sure that this isn't needed. That is
> concentrating on the vmbus driver.
Ok; I will look into this.
>
> > I will also address your comment on static initialization hv_driver instances
> > as part of other driver cleanup.
>
> No, please do this now as it will show how to properly interact with the
> vmbus core code in the correct manner. Hopefully that will be correct,
> but I have a feeling that it will show you some places in the API that
> need to be changed...
Will do.
Regards,
K. Y
^ permalink raw reply
* Re: various vmbus review comments
From: Greg KH @ 2011-05-04 16:32 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DFCFA@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Wed, May 04, 2011 at 04:20:11PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Tuesday, May 03, 2011 4:47 PM
> > To: KY Srinivasan
> > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: various vmbus review comments
> >
> > I just took a quick look at the vmbus code, and have the following
> > comments:
> > - why is count_hv_channel() even a function?
>
> I will fix this.
>
> > - your .h files need to be consolidated and renamed. You will
> > need a single hyperv.h file for include/linux/ that will
> > contain some of what the vmbus*.h files have in it, but not
> > all. Please merge things together to have:
> > - include/linux/hyperv.h
> > What is needed to build the drivers that attach to
> > the bus
> > - drivers/staging/hv/hyperv.h
> > The local .h file will have the vmbus*.h remaining
> > stuff that is only needed by the hv_vmbus.ko module
> > to be build.
>
> I have currently consolidated all the header files as follows:
>
> 1) hyperv.h - this will have all the vmbus related definitions
> needed to build drivers that attach to the bus (as you have suggested).
Great.
> 2) hyperv_storage.h - this has all the definitions needed to build storage
> drivers for Hyper-V. Storage drivers will include hyperv.h and
> hyperv_storage.h.
>
> 3) hyperv_net.h - this has all the definitions needed to build the network
> driver for Hyper-V. The netvsc driver will include hyperv.h and hyperv_net.h.
>
> 4) hyperv_utils.h - this has all the definitions needed to build the util driver.
> The util driver would include hyperv.h and hyperv_utils.h.
No for all 3 of these. Why would a simple driver need a .h file at all?
Just include the structures within the .c file, making it nice and
self-contained. There's no need to clutter things up, and individual
driver .h files should _never_ be in include/linux.
> All these four header files could potentially be under include/linux.
> I have also created a private header file that has the definitions to
> build the vmbus driver - hyperv_vmbus.h.
Sure, you can call it that, but as it will be local to the hyperv bus
directory, the name isn't all that important.
> Let me know if this is what you had in mind.
>
>
> > - the instances of hv_driver structures need to be static and
> > not programatically defined, like all other USB and PCI
> > drivers are handled.
> > - module reference counting. Are you sure you got it all right
> > for the individual modules that attach to the bus? I don't
> > see any reference counting happening, is that correct?
>
> For this round, I want to concentrate on just the vmbus driver. So,
> module reference counting is I don't think an issue for the vmbus driver
> given that the driver is not unlodable. Once I am done with the vmbus driver
> I will address the module reference counting issues for other drivers.
No, I am referring to the module reference counting of the bus drivers
that register with the vmbus core. You aren't doing that at all, and
you probably need to make sure that this isn't needed. That is
concentrating on the vmbus driver.
> I will also address your comment on static initialization hv_driver instances
> as part of other driver cleanup.
No, please do this now as it will show how to properly interact with the
vmbus core code in the correct manner. Hopefully that will be correct,
but I have a feeling that it will show you some places in the API that
need to be changed...
thanks,
greg k-h
^ permalink raw reply
* RE: various vmbus review comments
From: KY Srinivasan @ 2011-05-04 16:20 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110503204641.GA11132@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, May 03, 2011 4:47 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: various vmbus review comments
>
> I just took a quick look at the vmbus code, and have the following
> comments:
> - why is count_hv_channel() even a function?
I will fix this.
> - your .h files need to be consolidated and renamed. You will
> need a single hyperv.h file for include/linux/ that will
> contain some of what the vmbus*.h files have in it, but not
> all. Please merge things together to have:
> - include/linux/hyperv.h
> What is needed to build the drivers that attach to
> the bus
> - drivers/staging/hv/hyperv.h
> The local .h file will have the vmbus*.h remaining
> stuff that is only needed by the hv_vmbus.ko module
> to be build.
I have currently consolidated all the header files as follows:
1) hyperv.h - this will have all the vmbus related definitions
needed to build drivers that attach to the bus (as you have suggested).
2) hyperv_storage.h - this has all the definitions needed to build storage
drivers for Hyper-V. Storage drivers will include hyperv.h and
hyperv_storage.h.
3) hyperv_net.h - this has all the definitions needed to build the network
driver for Hyper-V. The netvsc driver will include hyperv.h and hyperv_net.h.
4) hyperv_utils.h - this has all the definitions needed to build the util driver.
The util driver would include hyperv.h and hyperv_utils.h.
All these four header files could potentially be under include/linux.
I have also created a private header file that has the definitions to
build the vmbus driver - hyperv_vmbus.h.
Let me know if this is what you had in mind.
> - the instances of hv_driver structures need to be static and
> not programatically defined, like all other USB and PCI
> drivers are handled.
> - module reference counting. Are you sure you got it all right
> for the individual modules that attach to the bus? I don't
> see any reference counting happening, is that correct?
For this round, I want to concentrate on just the vmbus driver. So,
module reference counting is I don't think an issue for the vmbus driver
given that the driver is not unlodable. Once I am done with the vmbus driver
I will address the module reference counting issues for other drivers.
I will also address your comment on static initialization hv_driver instances
as part of other driver cleanup.
> - fix the sparse warnings.
Will do. Just out of curiosity I ran sparse and was relieved to see only a handful
warnings!
> - fix the use of volatile in the ring buffer code. It should
> not be needed and if you are relying on it, then the code is
> wrong.
> - fix the namespace on the ringbuffer code to show that it
> really is only for the hyperv bus code internally.
I will fix these.
Regards,
K. Y
^ permalink raw reply
* RE: various vmbus review comments
From: KY Srinivasan @ 2011-05-03 22:49 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110503220354.GC14080@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, May 03, 2011 6:04 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: various vmbus review comments
>
> On Tue, May 03, 2011 at 09:00:01PM +0000, KY Srinivasan wrote:
> > You had also suggested that I should ask for a community review once
> > you had had applied my last set of patches. Now that you have applied
> > all my patches, should I formally ask for this review?
>
> I said something like "after my review comments are all handled". It
> wouldn't make much sense for more review when these comments aren't
> handled yet, right (note, some of these were made previously, so I
> wasn't the first to say them.)
>
> How about when I am happy, then we ask everyone else? I have a feeling
> that will take a while anyway :)
Fair enough; I will work on your comments first.
Regards,
K. Y
^ permalink raw reply
* Re: various vmbus review comments
From: Greg KH @ 2011-05-03 22:03 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DFA51@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Tue, May 03, 2011 at 09:00:01PM +0000, KY Srinivasan wrote:
> You had also suggested that I should ask for a community review once
> you had had applied my last set of patches. Now that you have applied
> all my patches, should I formally ask for this review?
I said something like "after my review comments are all handled". It
wouldn't make much sense for more review when these comments aren't
handled yet, right (note, some of these were made previously, so I
wasn't the first to say them.)
How about when I am happy, then we ask everyone else? I have a feeling
that will take a while anyway :)
thanks,
greg k-h
^ permalink raw reply
* RE: various vmbus review comments
From: KY Srinivasan @ 2011-05-03 21:00 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110503204641.GA11132@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, May 03, 2011 4:47 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: various vmbus review comments
>
> I just took a quick look at the vmbus code, and have the following
> comments:
> - why is count_hv_channel() even a function?
> - your .h files need to be consolidated and renamed. You will
> need a single hyperv.h file for include/linux/ that will
> contain some of what the vmbus*.h files have in it, but not
> all. Please merge things together to have:
> - include/linux/hyperv.h
> What is needed to build the drivers that attach to
> the bus
> - drivers/staging/hv/hyperv.h
> The local .h file will have the vmbus*.h remaining
> stuff that is only needed by the hv_vmbus.ko module
> to be build.
> - the instances of hv_driver structures need to be static and
> not programatically defined, like all other USB and PCI
> drivers are handled.
> - module reference counting. Are you sure you got it all right
> for the individual modules that attach to the bus? I don't
> see any reference counting happening, is that correct?
> - fix the sparse warnings.
> - fix the use of volatile in the ring buffer code. It should
> not be needed and if you are relying on it, then the code is
> wrong.
> - fix the namespace on the ringbuffer code to show that it
> really is only for the hyperv bus code internally.
>
> That should be enough for at least one more set of patches for you all
> to work on :)
Thanks for taking the time to review this code. I will start work on addressing
your comments right away. As we had discussed on this list, my goal is to deal
with the vmbus related issues first. You had also suggested that I should ask for
a community review once you had had applied my last set of patches. Now that
you have applied all my patches, should I formally ask for this review?
Regards,
K. Y
^ permalink raw reply
* various vmbus review comments
From: Greg KH @ 2011-05-03 20:46 UTC (permalink / raw)
To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, virtualization
I just took a quick look at the vmbus code, and have the following
comments:
- why is count_hv_channel() even a function?
- your .h files need to be consolidated and renamed. You will
need a single hyperv.h file for include/linux/ that will
contain some of what the vmbus*.h files have in it, but not
all. Please merge things together to have:
- include/linux/hyperv.h
What is needed to build the drivers that attach to
the bus
- drivers/staging/hv/hyperv.h
The local .h file will have the vmbus*.h remaining
stuff that is only needed by the hv_vmbus.ko module
to be build.
- the instances of hv_driver structures need to be static and
not programatically defined, like all other USB and PCI
drivers are handled.
- module reference counting. Are you sure you got it all right
for the individual modules that attach to the bus? I don't
see any reference counting happening, is that correct?
- fix the sparse warnings.
- fix the use of volatile in the ring buffer code. It should
not be needed and if you are relying on it, then the code is
wrong.
- fix the namespace on the ringbuffer code to show that it
really is only for the hyperv bus code internally.
That should be enough for at least one more set of patches for you all
to work on :)
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-02 22:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110502213511.GA5641@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Monday, May 02, 2011 5:35 PM
> To: KY Srinivasan
> Cc: Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Mon, May 02, 2011 at 09:16:36PM +0000, KY Srinivasan wrote:
> > > That assumes libata is a module, which it is not for many popular
> > > distributions.
> > >
> > As long as you can prevent ata_piix from loading, it should be fine.
>
> Again, this might very well be built in, e.g. take a look at:
>
> http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=config-
> generic;h=779415bcc036b922ba92de9c4b15b9da64e9707c;hb=HEAD
>
> http://gitorious.org/opensuse/kernel-
> source/blobs/master/config/x86_64/default
Good point! For what it is worth, last night I hacked up code
to present the block devices currently managed by the blkvsc
driver as scsi devices. I have still retained the blkvsc driver to
handshake with the host and sert up the channel etc. Rather than
presenting this device as an IDE device to the guest, as you had
suggested, I am adding this device as a scsi device under the HBA
implemented by the storvsc driver. I have assigned a special channel
number to distinguish these IDE disks, so that on the I/O paths we can
communicate over the appropriate channels. Given that the host is
completely oblivious to this arrangement on the guest, I suspect
we don't need to worry about future versions of Windows breaking this.
From, very minimal testing I have done, things appear to work well.
However, the motherboard emulation in Hyper-V requires the boot
device to be an IDE device and other than taking over the IDE majors, I don't
know of a way to prevent the native drivers from taking over the boot device.
On SLES, I had implemented modprobe rules to deal with the issue you had
mentioned; it is not clear what the general solution might be for this problem if any,
other than changes to the host.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-02 21:35 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DF56D@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Mon, May 02, 2011 at 09:16:36PM +0000, KY Srinivasan wrote:
> > That assumes libata is a module, which it is not for many popular
> > distributions.
> >
> As long as you can prevent ata_piix from loading, it should be fine.
Again, this might very well be built in, e.g. take a look at:
http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=config-generic;h=779415bcc036b922ba92de9c4b15b9da64e9707c;hb=HEAD
http://gitorious.org/opensuse/kernel-source/blobs/master/config/x86_64/default
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-02 21:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110502200012.GA21619@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Monday, May 02, 2011 4:00 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Mon, May 02, 2011 at 07:48:38PM +0000, KY Srinivasan wrote:
> > By setting up appropriate modprobe rules, this can be addressed.
>
> That assumes libata is a module, which it is not for many popular
> distributions.
>
As long as you can prevent ata_piix from loading, it should be fine.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-02 20:00 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, Greg KH, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DF543@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Mon, May 02, 2011 at 07:48:38PM +0000, KY Srinivasan wrote:
> By setting up appropriate modprobe rules, this can be addressed.
That assumes libata is a module, which it is not for many popular
distributions.
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-02 19:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110501205315.GC1017@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Sunday, May 01, 2011 4:53 PM
> To: KY Srinivasan
> Cc: Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote:
> > Could you elaborate on the problems/issues when the block driver registers for
> the
> > IDE majors. On the Qemu side, we have a mechanism to disable the emulation
> when
> > PV drivers load. I don't think there is an equivalent mechanism on the Windows
> side.
> > So, as far as I know, registering for the IDE majors is the only way to also
> prevent native
> > drivers in Linux from taking control of the emulated device.
>
> What qemu are you talking about for the qemu side? Upstream qemu
> doesn't have any way to provide the same image as multiple devices,
> nevermind dynamically unplugging bits in that case. Nor does it support
> the hyperv devices.
I am talking about the qemu that was (is) shipping with Xen. In Hyper-V,
the block devices configured as IDE devices for the guest will be taken over
by the native drivers if the PV drivers don't load first and take over the IDE majors.
If you want to have the root device be managed by the PV drivers, this appears to be
the only way to ensure that native IDE drivers don't take over the root device. Granted,
this depends on ensuring the PV drivers load first, but I don't know if there is another way
to achieve this.
>
> When you steal majors you rely on:
>
> a) loading earlier than the driver you steal them from
> b) the driver not simple using other numbers
> c) if it doesn't preventing it from working at all, also for
> devices you don't "replace" with your PV devices.
These are exactly the issues that had to be solved to have the PV
drivers manage the root device.
> d) that the guest actually uses the minors your claim, e.g. any
> current linux distribution uses libata anyway, so you old IDE
> major claim wouldn't do anything. Nor would claiming sd majors
> as the low-level libata driver would still drive the hardware
> even if SD doesn't bind to it.
By setting up appropriate modprobe rules, this can be addressed.
>
> You really must never present the same device as two emulated devices
> instead of doing such hacks.
Agreed; I am not sure what the right solution for Hyper-V is other than
(a) preventing the native IDE drivers from loading and (b) having
the right modprobe rules to ensure libata would not present these
same devices to the guest as scsi devices.
Regards,
K. Y
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox