hyperv: make HYPERV a menuconfig to ease disabling it all

No need to get into the submenu to disable all HYPERV-related config entries.

This makes it easier to disable all HYPERV config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu.

This is only intended to change menuconfig UI, not change the config dependencies.

Signed-off-by Vincent Legoll <[email protected]>

---
 drivers/hv/Kconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/hv/Kconfig +4 -1

index 50b89ea0e60f..5804081d936d 100644
@@ -1,4 +1,7 @@
-menu "Microsoft Hyper-V guest support"
+menuconfig HYPERV_MENU
+	bool "Microsoft Hyper-V guest support"
+
+if HYPERV_MENU
 
 config HYPERV
 	tristate "Microsoft Hyper-V client drivers"

Will this break existing configs?

Hello,

On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger <[email protected]> wrote:

Quoted 1 line

Will this break existing configs?

I don't think so. Last time I did some similar changes, the kbuild test robot found some warnings on some configurations, I hope it will find problems (if any) for that series too (this one is not alone, I've got a bunch of other similar patches in-flight)

Thanks

Quoted 4 lines · On Wed, 13 Dec 2017 09:54:19 +0100 Vincent Legoll <[email protected]>…

Hello,

On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger <[email protected]> wrote:

Quoted 8 lines

Quoted 1 line

Will this break existing configs?

I don't think so. Last time I did some similar changes, the kbuild test robot found some warnings on some configurations, I hope it will find problems (if any) for that series too (this one is not alone, I've got a bunch of other similar patches in-flight)

Thanks

NAK

Let me give a concrete example of how this will break users.

1. Assume user has a working .config file in their kernel build directory which builds a kernel that works on Hyper-V.

2. Add your patch (or assume it makes into a later version).

3. User then does

$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Microsoft Hyper-V guest support
*
Microsoft Hyper-V guest support (HYPERV_MENU) [N/y] (NEW) 

If they hit return, the default value is not enabling HyperV and they will then go on to build a kernel that will not boot on your system.

The default MUST be set to Yes.

Quoted 37 lines · Stephen Hemminger

Quoted 4 lines · On Wed, 13 Dec 2017 09:54:19 +0100 Vincent Legoll <[email protected]>…

Hello,

On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger <[email protected]> wrote:

Quoted 8 lines

Quoted 1 line

Will this break existing configs?

I don't think so. Last time I did some similar changes, the kbuild test robot found some warnings on some configurations, I hope it will find problems (if any) for that series too (this one is not alone, I've got a bunch of other similar patches in-flight)

Thanks

NAK

Let me give a concrete example of how this will break users.

1. Assume user has a working .config file in their kernel build directory which builds a kernel that works on Hyper-V.

2. Add your patch (or assume it makes into a later version).

3. User then does

$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Microsoft Hyper-V guest support
*
Microsoft Hyper-V guest support (HYPERV_MENU) [N/y] (NEW) 

Quoted 4 lines

If they hit return, the default value is not enabling HyperV and they will then go on to build a kernel that will not boot on your system.

The default MUST be set to Yes.

Or you can just not take these types of odd and silly changes to the Kconfig files, and leave it as-is. I have yet to see the good reason why these are needed at all.

Quoted 38 lines · Greg KH

Quoted 37 lines · Stephen Hemminger

Quoted 4 lines · On Wed, 13 Dec 2017 09:54:19 +0100 Vincent Legoll <[email protected]>…

Hello,

On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger <[email protected]> wrote:

Quoted 8 lines

Quoted 1 line

Will this break existing configs?

I don't think so. Last time I did some similar changes, the kbuild test robot found some warnings on some configurations, I hope it will find problems (if any) for that series too (this one is not alone, I've got a bunch of other similar patches in-flight)

Thanks

NAK

Let me give a concrete example of how this will break users.

1. Assume user has a working .config file in their kernel build directory which builds a kernel that works on Hyper-V.

2. Add your patch (or assume it makes into a later version).

3. User then does

$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Microsoft Hyper-V guest support
*
Microsoft Hyper-V guest support (HYPERV_MENU) [N/y] (NEW) 

Quoted 4 lines

Quoted 4 lines

If they hit return, the default value is not enabling HyperV and they will then go on to build a kernel that will not boot on your system.

The default MUST be set to Yes.

That should work.

Quoted 3 lines

Or you can just not take these types of odd and silly changes to the Kconfig files, and leave it as-is. I have yet to see the good reason why these are needed at all.

Some of us would like to be able to disable many like drivers at one time instead of having to go down a list of say 20-30 drivers and disable them one at a time.

It makes sense to organize the config if you dont break old configs. It would be more logical to group and treat all para-virtualized guest support in same way. Hyper-V should be next to KVM and Xen.