Matthias Fuchs wrote: > On Tuesday 03 November 2009 09:50, Oliver Hartkopp wrote: >> Wolfgang Grandegger schrieb: >>> Sebastian Haas wrote: >>> >>>> Imagine a GUI application which displays all available CAN channels. How >>>> does the user differ between 2 or 3 connected devices or just think >>>> about the 4 channel CPC-PCI board. How does the user know which can* >>>> device is which channel? >>>> >>> This could be done using the device renaming mechanism. >>> >>> >> Which would need a proper information exposure via sysfs to make udev happy. >> >>>> In our proprietary products we have a similiar situation as in Socket >>>> CAN. In Socket CAN you have abstract can* network interface to access >>>> the actual physical channel. In our library CPC-LIB you have CHAN*, >>>> these logical channels (CHAN*) must be configured using device >>>> information (e.g. CHAN00 is CPC-PCI board #1, channel #2, CHAN02 is >>>> CPC-USB with serial #1923). >>>> >>>> If the candev system would provide a common to get this information, a >>>> GUI display or even a terminal application can display additional >>>> information about each channel, so the user can decide which channel he >>>> wants to actually use. >>>> >>> Then it would make sense to add this to the device properties you can >>> get via the CAN netlink interface. Most likely you are interested in >>> other parameters like CAN statistics or bit-timinig as well. That's not >>> a big deal. They would then show up here: >>> >>> >>> $ ip -details -statistics link show can0 >>> 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen >>> 10 >>> link/can >>> can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100 >>> bitrate 125000 sample_point 0.875 >>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 >>> sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1 >>> clock 8000000 >>> board cpc-pci channel 2 serial# 123456 >>> >> Indeed this is a good step. IMO we we some kind of unique identifier for >> a CAN hardware. >> >> In the above example the serial number is a unique ID to identify the >> board. If you have a sja1000-isa (or mscan) setup with several >> controllers, the I/O port address would be the unique item. >> >> This could look like >> >> "board sja1000-isa port 0x320"
>> >> in the last line of your given example. >> >> Additionally to the possibility to get this kind of 'unique hardware ID' >> from netlink via 'ip link' probably the same unique ID could be provided >> in /sys/class/net/can0/canhwid or something like that ?!? >> >> E.g. >> $ cat /sys/class/net/can0/canhwid >> board cpc-pci channel 2 serial# 123456 One value per file, please. >> Any thoughts? > So we need sysfs and the netlink property stuff. Either sysfs *or* netlink, but not both. > > Do we want the driver to build the id string? Or should the driver provide a > couple > of separate information, that is concated by candev.ko for the canhwid. > > Going throuhg the last postings I found these more or less common information: > serial#, driver, channel#. What is "driver"? 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. > Some additional information might be: firmware/hardware version. Does this not come automatically with the firmware interface? > But how to implement the device specific control? When the sysfs > implementation's > purpose in to satisfy udev, device specific control should be implemented > through > netlink and we should implement a generic interface for this to the driver > layer. > I think it is important that such device specific control should not require > patching iproute2. I think we can forget the netlink support. The properties should go into /sys/class/can*/device/, as usual. I believe there are similar use-cases in the kernel and we should check how it's solved/implememented there. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
