On Tue, Nov 03, 2009 at 10:23:28AM +0100, 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.
But those would not be CAN related, but device related. Create them in
the device directory, accessible via /sys/class/net/canXX/device/
> > >>
> > >
> > > 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:
And create a bigger, heavier ip tool? I do not think the netlink
interface should be abused to implement manufacturer features. sysfs is
best for that.
> > >
> > >
> > > $ 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
this looks nice, but the extra info is used (I think) only for
identifying the device, not configuring.
I bet more features can be created than implemented.
> > >
> >
> > Indeed this is a good step. IMO we we some kind of unique identifier for
> > a CAN hardware.
IMHO, that's a bad idea. There is an ifindex already, and yet we have
the device name.
> >
> > 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
make it : $cat /sys/class/net/can0/device/canhwid.
That's much better
> >
> > Any thoughts?
> So we need sysfs and the netlink property stuff.
netlink for configuring the network interface, sysfs for getting device
info, but these are 2 different 'struct device' entries in the kernel.
>
> 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.
This, I agree.
>
> 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
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
