linux-kernel - Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220605192347.518c4b3c.max@enpas.org>
Date:   Sun, 5 Jun 2022 19:23:47 +0200
From:   Max Staudt <max@...as.org>
To:     Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>, linux-can@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        netdev@...r.kernel.org
Subject: Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild

Thanks Vincent for this cleanup!

Since I am upstreaming a driver that may (?) not fit the proposed
structure, one question below.


On Sun,  5 Jun 2022 01:29:53 +0900
Vincent Mailhol <mailhol.vincent@...adoo.fr> wrote:

> * menu after this series *
> 
> Network device support
>   symbol: CONFIG_NETDEVICES
>   |
>   +-> CAN Device Drivers
>       symbol: CONFIG_CAN_DEV
>       |
>       +-> software/virtual CAN device drivers
>       |   (at time of writing: slcan, vcan, vxcan)
>       |
>       +-> 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
>           |
>           +-> All other CAN devices not relying on RX offload
>           |
>           +-> CAN rx offload
>               symbol: CONFIG_CAN_RX_OFFLOAD
>               |
>               +-> CAN devices relying on rx offload
>                   (at time of writing: flexcan, m_can, mcp251xfd and
> ti_hecc)


This seemingly splits drivers into "things that speak to hardware" and
"things that don't". Except... slcan really does speak to hardware. It
just so happens to not use any of BITTIMING or RX_OFFLOAD. However, my
can327 (formerly elmcan) driver, which is an ldisc just like slcan,
*does* use RX_OFFLOAD, so where to I put it? Next to flexcan, m_can,
mcp251xfd and ti_hecc?

Is it really just a split by features used in drivers, and no longer a
split by virtual/real?


Max