Messages in this thread | | | Date | Tue, 1 Feb 2022 22:49:50 -0800 | From | Saeed Mahameed <> | Subject | Re: [PATCH net-next] net: kbuild: Don't default net vendor configs to y |
| |
On 02 Feb 06:30, Christophe Leroy wrote: > > >Le 02/02/2022 à 06:16, Saeed Mahameed a écrit : >> On 01 Feb 20:58, Jakub Kicinski wrote: >>> On Tue, 1 Feb 2022 20:46:03 -0800 Saeed Mahameed wrote: >>>> I am getting mixed messages here, on one hand we know that this patch >>>> might break some old or def configs, but on the other hand people claim >>>> that they have to manually fixup their own configs every time >>>> "something in configs" changes and they are fine with that. >>>> >>>> Obviously I belong to the 2nd camp, hence this patch.. >>>> >>>> I can sum it up with "it's fine to controllably break *some* .configs >>>> for >>>> the greater good" .. that's my .2cent. >>> >>> I think we agree that we don't care about oldconfigs IOW someone's >>> random config. >>> >>> But we do care about defconfigs in the tree, if those indeed include >>> ethernet drivers which would get masked out by vendor=n - they need >>> fixin': >>> >>> $ find arch/ | grep defconfig >>> arch/x86/configs/i386_defconfig >>> arch/x86/configs/x86_64_defconfig >>> arch/ia64/configs/generic_defconfig >>> arch/ia64/configs/gensparse_defconfig >>> ... >>> >>> First one from the top: >>> >>> $ make O=build_tmp/ i386_defconfig >>> $ $EDITOR drivers/net/ethernet/intel/Kconfig >>> $ git diff >>> diff --git a/drivers/net/ethernet/intel/Kconfig >>> b/drivers/net/ethernet/intel/Kconfig >>> index 3facb55b7161..b9fdf2a835b0 100644 >>> --- a/drivers/net/ethernet/intel/Kconfig >>> +++ b/drivers/net/ethernet/intel/Kconfig >>> @@ -5,7 +5,6 @@ >>> >>> config NET_VENDOR_INTEL >>> bool "Intel devices" >>> - default y >>> help >>> If you have a network (Ethernet) card belonging to this >>> class, say Y. >>> >>> $ make O=build_tmp/ i386_defconfig >>> $ diff -urpb build_tmp/.config.old build_tmp/.config >>> --- build_tmp/.config.old 2022-02-01 20:55:37.087373905 -0800 >>> +++ build_tmp/.config 2022-02-01 20:56:32.126044628 -0800 >>> @@ -1784,22 +1784,7 @@ CONFIG_NET_VENDOR_GOOGLE=y >>> # CONFIG_GVE is not set >>> CONFIG_NET_VENDOR_HUAWEI=y >>> # CONFIG_HINIC is not set >>> -CONFIG_NET_VENDOR_I825XX=y >>> -CONFIG_NET_VENDOR_INTEL=y >>> -CONFIG_E100=y >>> -CONFIG_E1000=y >>> -CONFIG_E1000E=y >>> -CONFIG_E1000E_HWTS=y >>> -# CONFIG_IGB is not set >>> -# CONFIG_IGBVF is not set >>> -# CONFIG_IXGB is not set >>> -# CONFIG_IXGBE is not set >>> -# CONFIG_IXGBEVF is not set >>> -# CONFIG_I40E is not set >>> -# CONFIG_I40EVF is not set >>> -# CONFIG_ICE is not set >>> -# CONFIG_FM10K is not set >>> -# CONFIG_IGC is not set >>> +# CONFIG_NET_VENDOR_INTEL is not set >> >> We can introduce CONFIG_NET_LEGACY_VENDOR that selects all current vendors. >> it will be off by default but will be added where needed in the defconfigs >
Sorry I think i messed up my previous reply, here it's again just in case.
>Why such a hack ? >
Reduced chance of error.
>I think we can fix all defconfig with some scripting, all you have to do >it to add the relevant CONFIG_NET_VENDOR_SOMEONE=y wherever you find one >of its boards in the defconfig. >
Such a script could easily mess up! I can't think of a clever easily verifiable way to map boards to their VENDORS. Add to that dispersing the VENDORS configs accurately.
I might be just tired though, i will give it a shot in the morning :)
>Christophe
| |