On Tue, 17 May 2022 10:50:16 +0900 Vincent MAILHOL <mailhol.vincent@xxxxxxxxxx> wrote: > 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? 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? > 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. I originally replied to PATCHv2 in agreement with what Vincent said in the first part - I agree that simply moving this code into can-dev and making v(x)can/slcan depend on it is the straightforward thing to do. Having yet another kernel module for a tiny bit of code adds more unnecessary complexity IMHO. And from a user perspective, it seems fairly natural to have can-dev loaded any time some can0, slcan0, vcan0, etc. pops up. Finally, embedded applications that are truly short on memory are likely using a "real" CAN adapter, and hence already have can-dev loaded anyway. I think it's okay to just move it to can-dev and call it a day :) Max
