[lkml]   [2022]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
On 17.05.2022 10:50:16, Vincent MAILHOL wrote:
> > would it probably make sense to
> > introduce a new can-skb module that could be used by all CAN
> > virtual/software interfaces?
> >
> > Or some other split-up ... any idea?
> My concern is: what would be the merrit? If we do not split, the users
> of slcan and v(x)can would have to load the can-dev module which will
> be slightly bloated for their use, but is this really an issue?

If you use modprobe all required modules are loaded automatically.

> I do
> not see how this can become a performance bottleneck, so what is the
> problem?
> I could also argue that most of the devices do not depend on
> rx-offload.o. So should we also split this one out of can-dev on the
> same basis and add another module dependency?

We can add a non user visible Kconfig symbol for rx-offload and let the
drivers that need it do a "select" on it. If selected the rx-offload
would be compiled into to can-dev module.

> The benefit (not having to load a bloated module for three drivers)
> does not outweigh the added complexity: all hardware modules will have
> one additional modprobe dependency on the tiny can-skb module.
> But as said above, I am not fully opposed to the split, I am just
> strongly divided. If we go for the split, creating a can-skb module is
> the natural and only option I see.
> If the above argument does not convince you, I will send a v3 with that split.


Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2022-05-17 08:09    [W:0.133 / U:22.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site