Hi Oliver, On Tuesday 03 November 2009 17:38, Oliver Hartkopp wrote: > 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 ... ack. > > 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 ;-) hmm, ... don't like to get hurt, but .. > > 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). I like both ways. But the canhwid is definetly what applications may need. > > 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. yes, and this does not forbit anyone to create other sysfs entries for special cases :-) > > <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. Looks good, but it contains some redundant information. Do we really need drvname and ioport in the canhwid?
Some interfaces have a user configurable id string. This one could be contained in the canhwid somehow. But how to set it? Or is this a totally different issue? > > For the "+5V on Pin1" use-case i would tend to a vendor specific > > /sys/class/net/can0/enable_5v_on_pin1 Ok. This could solve the user configurable id string issue above as well. It seems that the canhwid is the only common thing for all CAN nets. So this one should be handled commonly by candev, right? So perhaps a new function pointer field in struct can_priv to get the canhwid? Matthias > _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
