All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next] net: kbuild: Don't default net vendor configs to y
Date: Tue, 1 Feb 2022 10:58:01 +0200	[thread overview]
Message-ID: <Yfj2GTH3tHraprl0@unreal> (raw)
In-Reply-To: <09c97169-5f9a-fc8f-dea5-5423e7bfef34@twofifty.com>

On Mon, Jan 31, 2022 at 10:55:14AM -0800, Hisashi T Fujinaka wrote:
> On Mon, 31 Jan 2022, Florian Fainelli wrote:
> 
> > On 1/31/2022 10:35 AM, Saeed Mahameed wrote:
> > > On 31 Jan 19:30, Geert Uytterhoeven wrote:
> > > > On Mon, Jan 31, 2022 at 6:59 PM Stephen Hemminger
> > > > <stephen@networkplumber.org> wrote:
> > > > > On Mon, 31 Jan 2022 09:24:50 -0800
> > > > > Saeed Mahameed <saeed@kernel.org> wrote:
> > > > > 
> > > > > > From: Saeed Mahameed <saeedm@nvidia.com>
> > > > > >
> > > > > > NET_VENDOR_XYZ were defaulted to 'y' for no technical reason.
> > > > > >
> > > > > > Since all drivers belonging to a vendor are supposed to default to 'n',
> > > > > > defaulting all vendors to 'n' shouldn't be an issue, and aligns well
> > > > > > with the 'no new drivers' by default mentality.
> > > > > >
> > > > > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > > > > 
> > > > > This was done back when vendors were introduced in the
> > > > > network drivers tree.
> > > > > The default of Y allowed older configurations to just work.
> > > > 
> > > > And changing the defaults means all defconfigs must be updated first,
> > > > else the user's configs will end up without drivers needed.
> > > > 
> > > 
> > > As I understand correctly, at least for most common net drivers,
> > > having NET_VENDOR_XYZ=y doesn't actually build anything, we have
> > > flags per
> > > module for each vendor and those are defaulted to N.
> > 
> > Right, but once you start hiding NET_VENDOR_DRIVER_XYZ under a
> > NET_VENDOR_XYZ Kconfig symbol dependency, if NET_VENDOR_XYZ is not set
> > to Y, then you have no way to select NET_VENDOR_DRIVER_XYZ and so your
> > old defconfig breaks.
> > 
> > > 
> > > > > So there was a reason, not sure if it matters anymore.
> > > > > But it seems like useless repainting to change it now.
> > > > 
> > > > It might make sense to tune some of the defaults (i.e. change to
> > > > "default y if ARCH_*") for drivers with clear platform dependencies.
> > > > 
> > > 
> > > either set hard default to 'n' or just keep it as is, anything else is just
> > > more confusion.
> > 
> > Maybe the rule should go like this: any new driver vendor defaults to n,
> > and existing ones remain set to y, until we deprecate doing that and
> > switching them all off to n by 5.18?
> 
> Forgive my ignorance, but isn't it a regression if things quit working
> even if it's just a configuration change?

No, kernel configs never were declared as ABI as "regular" users are not
supposed to touch it. They use something provided by the distro.

> 
> From a user perspective I like having everything turned on initially so
> it just works. Pruning things down is a lot easier than trying to figure
> out what all to turn on. Especially in graphics.

I have completely opposite view here and prefer to have minimal config
for my CI, and for my working machines as well. 

Thanks

> 
> -- 
> Hisashi T Fujinaka - htodd at twofifty.com

WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Hisashi T Fujinaka <htodd@twofifty.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	David Awogbemila <awogbemila@google.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	rafal@milecki.pl, Horatiu Vultur <horatiu.vultur@microchip.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	Edwin Peer <edwin.peer@broadcom.com>,
	Wei Liu <wei.liu@kernel.org>,
	Michal Simek <michal.simek@xilinx.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	linux-sunxi@lists.linux.dev, Jiri Pirko <jiri@resnulli.us>,
	l.stelmach@samsung.com, Shay Agroskin <shayagr@amazon.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kernel@vger.kernel.org, Jon Mason <jdmason@kudzu.us>,
	Shannon Nelson <snelson@pensando.io>,
	Claudiu Beznea <claudiu.beznea@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Chris Snook <chris.snook@gmail.com>,
	Zhu Yanjun <zyjzyj2000@gmail.com>,
	Arthur Kiyanovski <akiyano@amazon.com>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	Gabriel Somlo <gsomlo@gmail.com>,
	Rain River <rain.1986.08.12@gmail.com>,
	Martin Habets <habetsm.xilinx@gmail.com>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	Shai Malin <smalin@marvell.com>,
	Maxime Ripard <mripard@kernel.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	drivers@pensando.io, Omkar Kulkarni <okulkarni@marvell.com>,
	linux-arm-kernel@lists.infradead.org,
	Vegard Nossum <vegard.nossum@oracle.com>,
	David Arinzon <darinzon@amazon.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	linux-renesas-soc@vger.kernel.org,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Catherine Sullivan <csully@google.com>,
	linux-hyperv@vger.kernel.org, oss-drivers@corigine.com,
	Noam Dagan <ndagan@amazon.com>, Rob Herring <robh@kernel.org>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Dexuan Cui <decui@microsoft.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Chen-Yu Tsai <wens@csie.org>, Joel Stanley <joel@jms.id.au>,
	Simon Horman <simon.horman@corigine.com>,
	Asmaa Mnebhi <asmaa@nvidia.com>, Arnd Bergmann <arnd@arndb.de>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Saeed Mahameed <saeed@kernel.org>,
	Liming Sun <limings@nvidia.com>,
	Michael Chan <michael.chan@broadcom.com>,
	Salil Mehta <salil.mehta@huawei.com>,
	Sergey Shtylyov <s.shtylyov@omp.ru>,
	Oleksij Rempel <linux@rempel-privat.de>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Saeed Bishara <saeedb@amazon.com>,
	Mark Einon <mark.einon@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Slark Xiao <slark_xiao@163.com>, Gary Guo <gary@garyguo.net>,
	Gerhard Engleder <gerhard@engleder-embedded.com>,
	Jeroen de Borst <jeroendb@google.com>,
	Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	intel-wired-lan@lists.osuosl.org,
	Jakub Kicinski <kuba@kernel.org>,
	Prabhakar Kushwaha <pkushwaha@marvell.com>,
	Hans Ulli Kroll <ulli.kroll@googlemail.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Marcin Wojtas <mw@semihalf.com>,
	David Thompson <davthompson@nvidia.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	netdev@vger.kernel.org,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next] net: kbuild: Don't default net vendor configs to y
Date: Tue, 1 Feb 2022 10:58:01 +0200	[thread overview]
Message-ID: <Yfj2GTH3tHraprl0@unreal> (raw)
In-Reply-To: <09c97169-5f9a-fc8f-dea5-5423e7bfef34@twofifty.com>

On Mon, Jan 31, 2022 at 10:55:14AM -0800, Hisashi T Fujinaka wrote:
> On Mon, 31 Jan 2022, Florian Fainelli wrote:
> 
> > On 1/31/2022 10:35 AM, Saeed Mahameed wrote:
> > > On 31 Jan 19:30, Geert Uytterhoeven wrote:
> > > > On Mon, Jan 31, 2022 at 6:59 PM Stephen Hemminger
> > > > <stephen@networkplumber.org> wrote:
> > > > > On Mon, 31 Jan 2022 09:24:50 -0800
> > > > > Saeed Mahameed <saeed@kernel.org> wrote:
> > > > > 
> > > > > > From: Saeed Mahameed <saeedm@nvidia.com>
> > > > > >
> > > > > > NET_VENDOR_XYZ were defaulted to 'y' for no technical reason.
> > > > > >
> > > > > > Since all drivers belonging to a vendor are supposed to default to 'n',
> > > > > > defaulting all vendors to 'n' shouldn't be an issue, and aligns well
> > > > > > with the 'no new drivers' by default mentality.
> > > > > >
> > > > > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > > > > 
> > > > > This was done back when vendors were introduced in the
> > > > > network drivers tree.
> > > > > The default of Y allowed older configurations to just work.
> > > > 
> > > > And changing the defaults means all defconfigs must be updated first,
> > > > else the user's configs will end up without drivers needed.
> > > > 
> > > 
> > > As I understand correctly, at least for most common net drivers,
> > > having NET_VENDOR_XYZ=y doesn't actually build anything, we have
> > > flags per
> > > module for each vendor and those are defaulted to N.
> > 
> > Right, but once you start hiding NET_VENDOR_DRIVER_XYZ under a
> > NET_VENDOR_XYZ Kconfig symbol dependency, if NET_VENDOR_XYZ is not set
> > to Y, then you have no way to select NET_VENDOR_DRIVER_XYZ and so your
> > old defconfig breaks.
> > 
> > > 
> > > > > So there was a reason, not sure if it matters anymore.
> > > > > But it seems like useless repainting to change it now.
> > > > 
> > > > It might make sense to tune some of the defaults (i.e. change to
> > > > "default y if ARCH_*") for drivers with clear platform dependencies.
> > > > 
> > > 
> > > either set hard default to 'n' or just keep it as is, anything else is just
> > > more confusion.
> > 
> > Maybe the rule should go like this: any new driver vendor defaults to n,
> > and existing ones remain set to y, until we deprecate doing that and
> > switching them all off to n by 5.18?
> 
> Forgive my ignorance, but isn't it a regression if things quit working
> even if it's just a configuration change?

No, kernel configs never were declared as ABI as "regular" users are not
supposed to touch it. They use something provided by the distro.

> 
> From a user perspective I like having everything turned on initially so
> it just works. Pruning things down is a lot easier than trying to figure
> out what all to turn on. Especially in graphics.

I have completely opposite view here and prefer to have minimal config
for my CI, and for my working machines as well. 

Thanks

> 
> -- 
> Hisashi T Fujinaka - htodd@twofifty.com

  reply	other threads:[~2022-02-01  8:58 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 17:24 [Intel-wired-lan] [PATCH net-next] net: kbuild: Don't default net vendor configs to y Saeed Mahameed
2022-01-31 17:24 ` Saeed Mahameed
2022-01-31 17:59 ` [Intel-wired-lan] " Stephen Hemminger
2022-01-31 17:59   ` Stephen Hemminger
2022-01-31 18:30   ` [Intel-wired-lan] " Geert Uytterhoeven
2022-01-31 18:30     ` Geert Uytterhoeven
2022-01-31 18:35     ` [Intel-wired-lan] " Saeed Mahameed
2022-01-31 18:35       ` Saeed Mahameed
2022-01-31 18:40       ` [Intel-wired-lan] " Florian Fainelli
2022-01-31 18:40         ` Florian Fainelli
2022-01-31 18:55         ` [Intel-wired-lan] " Hisashi T Fujinaka
2022-01-31 18:55           ` Hisashi T Fujinaka
2022-02-01  8:58           ` Leon Romanovsky [this message]
2022-02-01  8:58             ` Leon Romanovsky
2022-02-01 15:46             ` Richard Cochran
2022-02-01 15:46               ` Richard Cochran
2022-01-31 19:17         ` Richard Cochran
2022-01-31 19:17           ` Richard Cochran
2022-01-31 20:10         ` [Intel-wired-lan] " Jakub Kicinski
2022-01-31 20:10           ` Jakub Kicinski
2022-01-31 23:06           ` [Intel-wired-lan] " Florian Fainelli
2022-01-31 23:06             ` Florian Fainelli
2022-01-31 23:13             ` [Intel-wired-lan] " Jakub Kicinski
2022-01-31 23:13               ` Jakub Kicinski
2022-01-31 23:19               ` [Intel-wired-lan] " Florian Fainelli
2022-01-31 23:19                 ` Florian Fainelli
2022-02-02  4:46                 ` [Intel-wired-lan] " Saeed Mahameed
2022-02-02  4:46                   ` Saeed Mahameed
2022-02-02  4:58                   ` [Intel-wired-lan] " Jakub Kicinski
2022-02-02  4:58                     ` Jakub Kicinski
2022-02-02  5:16                     ` [Intel-wired-lan] " Saeed Mahameed
2022-02-02  5:16                       ` Saeed Mahameed
2022-02-02  6:30                       ` [Intel-wired-lan] " Christophe Leroy
2022-02-02  6:30                         ` Christophe Leroy
2022-02-02  6:44                         ` [Intel-wired-lan] " Saeed Mahameed
2022-02-02  6:44                           ` Saeed Mahameed
2022-02-02  6:49                         ` [Intel-wired-lan] " Saeed Mahameed
2022-02-02  6:49                           ` Saeed Mahameed
2022-02-02 15:17                           ` [Intel-wired-lan] " Richard Cochran
2022-02-02 15:17                             ` Richard Cochran
2022-02-02 15:31                             ` [Intel-wired-lan] " Arnd Bergmann
2022-02-02 15:31                               ` Arnd Bergmann
2022-01-31 18:31   ` [Intel-wired-lan] " Saeed Mahameed
2022-01-31 18:31     ` Saeed Mahameed
2022-01-31 18:04 ` [Intel-wired-lan] " Shannon Nelson
2022-01-31 18:04   ` Shannon Nelson
2022-01-31 19:13   ` [Intel-wired-lan] " Richard Cochran
2022-01-31 19:13     ` Richard Cochran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yfj2GTH3tHraprl0@unreal \
    --to=leon@kernel.org \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.