Messages in this thread | | | Date | Tue, 17 May 2022 15:43:01 +0200 | From | Max Staudt <> | Subject | Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c |
| |
On Tue, 17 May 2022 15:35:03 +0200 Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Oh, I didn't want to introduce two new kernel modules but to have > can_dev in different 'feature levels'.
Which I agree is a nice idea, as long as heisenbugs can be avoided :)
(as for the separate modules vs. feature levels of can-dev - sorry, my two paragraphs were each referring to a different idea. I mixed them into one single email...)
Maybe the can-skb and rx-offload parts could be a *visible* sub-option of can-dev in Kconfig, which is normally optional, but immediately force-selected once a CAN HW driver is selected?
> But e.g. the people that are running Linux instances in a cloud only > using vcan and vxcan would not need to carry the entire > infrastructure of CAN hardware support and rx-offload.
Out of curiosity, do you have an example use case for this vcan cloud setup? I can't dream one up...
Max
| |