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(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 50b89ea0e60f..5804081d936d 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -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"
@@ -23,4 +26,4 @@ config HYPERV_BALLOON
help
Select this option to enable Hyper-V Balloon driver.
-endmenu
+endif # HYPERV_MENU
--
2.14.1
On Sat, 9 Dec 2017 16:21:51 +0100
Vincent Legoll <[email protected]> wrote:
> 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(-)
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 50b89ea0e60f..5804081d936d 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -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"
> @@ -23,4 +26,4 @@ config HYPERV_BALLOON
> help
> Select this option to enable Hyper-V Balloon driver.
>
> -endmenu
> +endif # HYPERV_MENU
Will this break existing configs?
Hello,
On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
<[email protected]> wrote:
> 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
--
Vincent Legoll
On Wed, 13 Dec 2017 09:54:19 +0100
Vincent Legoll <[email protected]> wrote:
> Hello,
>
> On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
> <[email protected]> wrote:
> > 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.
On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Dec 2017 09:54:19 +0100
> Vincent Legoll <[email protected]> wrote:
>
> > Hello,
> >
> > On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
> > <[email protected]> wrote:
> > > 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.
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.
thanks,
greg k-h
On 12/13/2017 11:51 PM, Greg KH wrote:
> On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote:
>> On Wed, 13 Dec 2017 09:54:19 +0100
>> Vincent Legoll <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
>>> <[email protected]> wrote:
>>>> 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.
That should work.
> 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.
--
~Randy
Hello,
The following patch add a "default y" to the menuconfig to avoid breaking
existing configs.
Please advise if this is better, and sufficient.
Tell me if these kind of changes are not welcome in the kernel, so that I
won't continue with other similar work. I am an actual user of menuconfig,
and find it really harder to use than necessary. A lot of new drivers and
config options have been added, with only a few relevant to my HW.
It is getting very hard to go through menuconfig and disable all the
unneeded stuff.
I use distro kernels on some of my HW, but for the smaller armels or i686s,
I actually want to strip the kernel config.
I find the existing menuconfigs a good solution for that problem, because
they allow me to disable huge lists of stuff when I know I don't need them
without even bothering to enter the menu, an go to each one disabling it.
I may not doing it all right, but I think this kind of patch helps at least
some of us. Please advise if there's a better way.
Thanks
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.
v2: added "default y" to avoid breaking existing configs
Signed-off-by: Vincent Legoll <[email protected]>
---
drivers/hv/Kconfig | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 50b89ea0e60f..a6cda712135f 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -1,4 +1,8 @@
-menu "Microsoft Hyper-V guest support"
+menuconfig HYPERV_MENU
+ bool "Microsoft Hyper-V guest support"
+ default y
+
+if HYPERV_MENU
config HYPERV
tristate "Microsoft Hyper-V client drivers"
@@ -23,4 +27,4 @@ config HYPERV_BALLOON
help
Select this option to enable Hyper-V Balloon driver.
-endmenu
+endif # HYPERV_MENU
--
2.14.1
On Thu, 14 Dec 2017 09:43:48 -0800
Randy Dunlap <[email protected]> wrote:
> On 12/13/2017 11:51 PM, Greg KH wrote:
> > On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote:
> >> On Wed, 13 Dec 2017 09:54:19 +0100
> >> Vincent Legoll <[email protected]> wrote:
> >>
> >>> Hello,
> >>>
> >>> On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
> >>> <[email protected]> wrote:
> >>>> 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.
>
> That should work.
>
> > 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.
Hello,
On Sat, Dec 16, 2017 at 6:51 PM, Stephen Hemminger
<[email protected]> wrote:
> 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.
I agree, I can try to work on that too, as it would nicely complement
the menuconfigifcation.
--
Vincent Legoll