I do think sockets will be the way to go for pretty much all of the interfaces. CAN and single wire CAN are obvious candidates for going with a native socketcan interface. Some of the other protocols might be a bit of a stretch. But, there exists two possibilities.
-
We can create another socket type for them. Currently you can create TCP, UDP, etc or CAN sockets in LINUX. It’d be possible to create something akin to socketcan but instead it uses a different socket type, perhaps K-LINE could be a socket type for instance. This would be kind of a bum deal as other programs would need to be specifically written to take advantage of the new socket types.
-
Make everything a socketcan interface and fudge the details to match. I don’t think all of the other protocols have the same ID and data configuration as CAN and not all of them are broadcast buses like CAN but those low level details can likely be abstracted away. Then every interface can exist with a socketcan compatible interface. Technically CAN frames have either 11 or 29 bit IDs but you’d need to store the ID in a 32 bit field. So, the upper 3 bits could even be abused to specify protocol. 0 = CAN, 1 = LIN, 2 = K-Line, etc. Then you’d have that info right in the ID but perhaps that isn’t necessary. We’d already know that a given interface only supports a specific protocol. The end result would be that it’s possible to capture and send LIN traffic or some other interface type from any normal socketcan compatible program. However, some socketcan programs might be hard coded to expect no more than 8 data bytes. Some of the other interfaces can send and receive larger payloads. But, CAN-FD already goes up to 64 bytes and that’s possible in modern socketcan implementations so the danger should be limited.
I think option 2 would work fine. If someone wants to do that then that’s great. I can assist as needed.