Hi Matthias, Matthias Fuchs wrote: > 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.
OK, I see. >> >> 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: The rule is one value per file. If it's an id string, like in the modalias, it's fine. >> 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## This looks like a modalias string. How is it related? >> 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 I can understand that /sys/class/net/can*/ is a convenient location, but please check what is found in /sys/class/net/*/ and judge yourself if the directory is appropriate for hardware related device properties. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
