Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c

[Max Staudt <max@enpas.org>]

On Tue, 17 May 2022 14:21:53 +0200
Marc Kleine-Budde <mkl@pengutronix.de> wrote:

> On 17.05.2022 14:14:04, Max Staudt wrote:
> > > After looking through drivers/net/can/Kconfig I would probably
> > > phrase it like this:
> > > 
> > > Select CAN devices (hw/sw) -> we compile a can_dev module. E.g.
> > > to handle the skb stuff for vcan's.
> > > 
> > > Select hardware CAN devices -> we compile the netlink stuff into
> > > can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled
> > > into can_dev too.
> > > 
> > > In the latter case: The selection of flexcan, ti_hecc and
> > > mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also
> > > compiled into can_dev.
> > > 
> > > Would that fit in terms of complexity?  
> > 
> > IMHO these should always be compiled into can-dev. Out of tree
> > drivers are fairly common here, and having to determine which kind
> > of can-dev (stripped or not) the user has on their system is a
> > nightmare waiting to happen.  
> 
> I personally don't care about out-of-tree drivers.

I know that this is the official stance in the kernel.

But out-of-tree drivers do happen on a regular basis, even when
developing with the aim of upstreaming. And if a developer builds a
minimal kernel to host a CAN driver, without building in-tree hardware
CAN drivers, then can-dev will be there but behave differently from
can-dev in a full distro. Leading to heisenbugs and wasting time. The
source of heisenbugs really are the suggested *hidden* Kconfigs.


On another note, is the module accounting overhead in the kernel for
two new modules with relatively little code in each, code that almost
always is loaded when CAN is used, really worth it?


Okay, I think I'm out of 2 cent pieces now :)


Max