Re: [PATCH net-next] net: kbuild: Don't default net vendor configs to y

[Saeed Mahameed]

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