I realize this is premature because v2.90~18 isn't yet in beta but there are issues with the changed interface that may cause users/installers problems.
I'm working on a rewrite to VeCanSetup to accommodate additional CANbus ports supported with Venus OS v2.90~18. I've got things working with the old model of adding services, udev rules and relates shell scripts and updating the /etc/venus/canbus_ports file. A CANableIO USB interface works after boot and after unplugging/replugging.
I had to add an udevadm trigger -y can 0, etc to the add.sh to get replug working.
I no longer install services associated with the port as it seems the system does this now.
Venus OS appears to automatically install all bus slcand type devices. There is no opportunity to configure them in VeCanSetup. Any udev rules and shell scripts for these devices added here are simply ignored.
jhofstee posted an issue in my VeCanSetup GitHub repo regarding CANbus names. Unfortunately this is never going to work for devices/ports added outside the OS build. As mentioned above, Venus OS is managing all but slcand devices so any rules created with VeCanSetup are ignored. For slcand devices, a second user space device is created by slcand and the parameters associated with the USB device do not propagate to the device in net space. So adding (ENV{VE_NAME}="custom name goes here") has affect. Naming ports may be essential if a system has more than two ports.
The biggest issue I see:
Prior to v2.90~18, I could define a port that would consistently bind a device by vendor/model/serial number to a specific CANbus port. I can still do this for devices using slcand but not if Venus OS gets to the device first (devices that don't use slcand). Detection order during boot or replugging may upset the port configurations: what was the BMS CANbus port could end up being connected to the RV-C CANbus.
