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 > > Any thoughts? So we need sysfs and the netlink property stuff.
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#. Some additional information might be: firmware/hardware version. 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. Matthias > > Regards, > Oliver > > _______________________________________________ > Socketcan-core mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/socketcan-core > > -- ------------------------------------------------------------------------- Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany ------------------------------------------------------------------------- Geschäftsführer: Klaus Detering, Dr. Werner Schulze Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 ------------------------------------------------------------------------- _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
