Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220513142355.250389-1-mailhol.vincent@wanadoo.fr>
 <20220604163000.211077-1-mailhol.vincent@wanadoo.fr> <2e8666f3-1bd9-8610-6b72-e56e669d3484@hartkopp.net>
 <CAMZ6RqKWUyf6dZmxG809-yvjg5wbLwPSLtEfv-MgPpJ5ra=iGQ@mail.gmail.com>
 <f161fdd0-415a-8ea1-0aad-3a3a19f1bfa8@hartkopp.net> <20220607202706.7fbongzs3ixzpydm@pengutronix.de>
 <44670e69-6d67-c6c7-160c-1ae6e740aabb@hartkopp.net>
In-Reply-To: <44670e69-6d67-c6c7-160c-1ae6e740aabb@hartkopp.net>
From:   Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Date:   Wed, 8 Jun 2022 08:59:51 +0900
Message-ID: <CAMZ6RqJq70qv97oNbNXL6z+52b3pyg9rBNNd4BKmpO4-6Xg=Gw@mail.gmail.com>
Subject: Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild
To:     Oliver Hartkopp <socketcan@hartkopp.net>
Cc:     Marc Kleine-Budde <mkl@pengutronix.de>,
        linux-can <linux-can@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Max Staudt <max@enpas.org>, netdev <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed. 8 Jun 2022 at 05:51, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 07.06.22 22:27, Marc Kleine-Budde wrote:
> > On 07.06.2022 22:12:46, Oliver Hartkopp wrote:
> >> So what about:
> >>
> >>    symbol: CONFIG_NETDEVICES
> >>    |
> >>    +-> CAN Device Drivers
> >>        symbol: CONFIG_CAN_DEV
> >>        |
> >>        +-> software/virtual CAN device drivers
> >>        |   (at time of writing: slcan, vcan, vxcan)
> >>        |
> >>        +-> hardware CAN device drivers with Netlink support
> >>            symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV)
> >>            |
> >>            +-> CAN bit-timing calculation (optional for all drivers)
> >>            |   symbol: CONFIG_CAN_BITTIMING
> >>            |
> >>            +-> CAN rx offload (optional but selected by some drivers)
> >>            |   symbol: CONFIG_CAN_RX_OFFLOAD
> >>            |
> >>            +-> CAN devices drivers
> >>                (some may select CONFIG_CAN_RX_OFFLOAD)

OK, this does not follow the definition I set for the "x --> y" arrow,
but it is easy to read. I am OK with your suggestion. I will also
remove the definition of the "x --> y" arrow because your diagram is
self explanatory.

> >> (I also added 'hardware' to CAN device drivers with Netlink support) to have
> >> a distinction to 'software/virtual' CAN device drivers)

This line you modified is the verbatim copy of the title in
menuconfig. So you are suggesting adding "hardware" to the menuconfig
as well? It did not have this word in the title before this series.
I was hesitating on this. If we name the symbol CAN_NETLINK, then I do
not see the need to also add "hardware" in the title. If you look at
the help menu, you will see: "This is required by all platform and
hardware CAN drivers." Mentioning it in the help menu is enough for
me.

And because of the blur line between slcan (c.f. Marc's comment
below), I am not convinced to add this.

> > The line between hardware and software/virtual devices ist blurry, the
> > new can327 driver uses netlink and the slcan is currently being
> > converted....
>
> Right, which could mean that slcan and can327 should be located in the
> 'usual' CAN device driver section and not in the sw/virtual device section.

ACK, but as discussed with Marc, I will just focus on the series
itself and ignore (for the moment) that slcan will probably be moved
within CAN_NETLINK scope in the future.
https://lore.kernel.org/linux-can/20220607103923.5m6j4rykvitofsv4@pengutronix.de/

> The slcan and can327 need some kind of hardware - while vcan and vxcan
> don't.


Yours sincerely,
Vincent Mailhol