Matthias Fuchs wrote: >> The version string of the device driver is not a per >> device property. At the moment, I just see hardware name, channel and >> serial number. > Hmm, doesn't /sys/class/can*/device point to the same device when it's a multi > channel hardware? Then it's difficult to identify net x of device y, right? >
Yes, i also see this to become a problem. The canhwid is something unique like the /sys/class/net/eth0/address for ethernet devices. So IMO it needs to be in /sys/class/net/can0/canhwid ... As the 'address' and the 'addr_len' both can be set be the driver we would also be able to use this pair of already defined sysfs entries - but i assume, we will be punished for that suggestion ;-) Remembering Wolfgangs point to have separate entries for vendor/serialnumber/etc is something i have a problem with: A canhwid is something unique that can only be built by the driver, as *only* the driver knows, how to build a unique string out of it's configuration (regarding serial numbers, ioports, whatever). Providing vendor names and product information in a string format in the sysfs is _not_ usual. And 'scanning' for CAN specific values in sysfs to find something unique will lead to a udev scripting hell. Maybe after all this discussion and after coming back to sysfs the idea behind a driver generated unique canhwid has become clearer. IMO we could define a common specification, how the canhwid has to be built by the driver, e.g. <drvname>#<vendor>#<product>#<serialnumber>#<ioport>#<channel># cpc-pcmcia#EMS Wuensche#CPC-Card#12345678#0x1000#0# sja1000-isa###0x320## Just an idea, which could be easily handled by udev. For the "+5V on Pin1" use-case i would tend to a vendor specific /sys/class/net/can0/enable_5v_on_pin1 or something like this. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
