netdev - Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZ6Rq+vYNvrTcToqVqqKSPJXAdjs3RkUY_SNuwB7n9FMuqQiQ@mail.gmail.com>
Date:   Wed, 8 Jun 2022 08:40:19 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Max Staudt <max@...as.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD

On Wed. 8 Jun 2022 à 07:06, Jakub Kicinski <kuba@...nel.org> wrote:
> On Tue, 7 Jun 2022 18:22:16 +0200 Max Staudt wrote:
> > > Honestly, I am totally happy to have the "default y" tag, the "if
> > > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together.
> > >
> > > Unless I am violating some kind of best practices, I prefer to keep it
> > > as-is. Hope this makes sense.
>
> AFAIU Linus likes for everything that results in code being added to
> the kernel to default to n.

A "make defconfig" would not select CONFIG_CAN (on which
CAN_RX_OFFLOAD indirectly depends) and so by default this code is not
added to the kernel.

> If the drivers hard-select that Kconfig
> why bother user with the question at all? My understanding is that
> Linus also likes to keep Kconfig as simple as possible.

I do not think that this is so convoluted. What would bother me is
that RX offload is not a new feature. Before this series, RX offload
is built-in the can-dev.o by default. If this new CAN_RX_OFFLOAD does
not default to yes, then the default features built-in can-dev.o would
change before and after this series.
But you being one of the maintainers, if you insist I will go in your
direction. So will removing the "default yes" and the comment "If
unsure, say yes" from the CAN_RX_OFFLOAD satisfy you?

> > I wholeheartedly agree with Vincent's decision.
> >
> > One example case would be users of my can327 driver, as long as it is
> > not upstream yet. They need to have RX_OFFLOAD built into their
> > distribution's can_dev.ko, otherwise they will have no choice but to
> > build their own kernel.
>
> Upstream mentioning out-of-tree modules may have the opposite effect
> to what you intend :( Forgive my ignorance, what's the reason to keep
> the driver out of tree?

I can answer for Max. The can327 patch is under review with the clear
intent to have it upstream. c.f.:
https://lore.kernel.org/linux-can/20220602213544.68273-1-max@enpas.org/

But until the patch gets accepted, it is defacto an out of tree module.

Yours sincerely,
Vincent Mailhol