On Tue, 7 Jun 2022 18:27:55 +0900 Vincent MAILHOL <mailhol.vincent@xxxxxxxxxx> wrote: > Second, and regardless of the above, I really think that it makes > sense to have everything built in can-dev.ko by default. If someone > does a binary release of can-dev.ko in which the rx offload is > deactivated, end users would get really confused. > > Having a can-dev module stripped down is an expert setting. The > average user which does not need CAN can deselect CONFIG_CAN and be > happy. The average hobbyist who wants to do some CAN hacking will > activate CONFIG_CAN and will automatically have the prerequisites in > can-dev for any type of device drivers (after that just need to select > the actual device drivers). The advanced user who actually read all > the help menus will know that he should rather keep those to "yes" > throughout the "if unsure, say Y" comment. Finally, the experts can > fine tune their configuration by deselecting the pieces they did not > wish for. > > Honestly, I am totally happy to have the "default y" tag, the "if > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together. > > Unless I am violating some kind of best practices, I prefer to keep it > as-is. Hope this makes sense. I wholeheartedly agree with Vincent's decision. One example case would be users of my can327 driver, as long as it is not upstream yet. They need to have RX_OFFLOAD built into their distribution's can_dev.ko, otherwise they will have no choice but to build their own kernel. Max
