From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Networking for 5.17
Date: Mon, 10 Jan 2022 21:02:47 -0800 [thread overview]
Message-ID: <CAHk-=wieO-N=XD73D=OKJ88Y_=GiF9OGm2yg3s_nvafPxAFYwg@mail.gmail.com> (raw)
In-Reply-To: <20220110205603.6bc9b680@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Mon, Jan 10, 2022 at 8:56 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> The only explanation I can come up with it's that it was
> done so that people running olddefconfig right after the per-vendor
> split was introduced wouldn't lose all drivers.
Yeah, I think that was the reason. Don't hide existing drivers behind
vendors that got turned off.
I think it would probably be fine to have entirely new vendors (ie "no
existing drivers") default to 'n' when added, just to cut down on the
huge amount of driver questions.
But right now they all act the other way around, and are just a way to
explicitly turn off questions for a vendor you know you don't care
about.
It does perhaps get a bit confusing if some vendors are 'default y'
and others are 'default n'. It's easy enough to explain at the time
when that vendor is added, but then ten years passes, and somebody
asks why something like DEC or 3com is 'default y', while soem big new
vendor migth be 'default n'.
So I dunno.
Linus
next prev parent reply other threads:[~2022-01-11 5:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 2:52 [GIT PULL] Networking for 5.17 Jakub Kicinski
2022-01-11 3:20 ` pr-tracker-bot
2022-01-11 3:31 ` Linus Torvalds
2022-01-11 3:42 ` Linus Torvalds
2022-01-11 4:56 ` Jakub Kicinski
2022-01-11 5:02 ` Linus Torvalds [this message]
2022-01-11 16:01 ` Nathan Chancellor
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='CAHk-=wieO-N=XD73D=OKJ88Y_=GiF9OGm2yg3s_nvafPxAFYwg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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.