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. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
