On 10.11.2010 20:20, Stephen Hellriegel wrote:
> Our hardware uses the "serial" number field of the USB stack to map to a
> device position on the board.
(..)
> we have the TTYUSB# and the "Serial" number which allows us to map the serial
> number to the can# we want the device to show up on.
Ok - got that.
> We run a script that in essence does the following:
> NUM = can number we want (ie can0...can7)
> stty swtch $NUM -F /dev/$TTY
> slcand $TTY
> sleep 0.5
> ifconfig can${NUM} up
>
> and then our requests can interface is up, and bound to the $TTY port.
As i assumed you have the $TTY and the $NUM mapped at some point.
But the stty hack is bad.
As the created netdevice name is already available from the /dev/$TTY via
ioctl(), i would suggest to move the initialization process to the following:
NUM = can number we want (ie can0...can7)
slcand $TTY can{$NUM}
sleep 0.5
ifconfig can${NUM} up
For that reason the slcan.c (and slip.c) already supports the SIOCGIFNAME
ioctl():
case SIOCGIFNAME:
tmp = strlen(sl->dev->name) + 1;
if (copy_to_user((void __user *)arg, sl->dev->name, tmp))
return -EFAULT;
return 0;
So the better approach would be to come up e.g. with a different naming scheme
slcan0, slcan1, ... and then rename the netdevice to the wanted can0.
The slcand would do the following:
1. open /dev/$TTY
2. perform the ioctl (fd, TIOCSETD, &ldisc) and create the netdevice
3. get the created netdevice name with SIOCGIFNAME from /dev/$TTY
4. rename the netdevice to can{$NUM} (with netlink?)
IMO the stty swtch stuff is not only a misuse of the swtch char - it is also
avoidable by using existing ioctls known from slip.c . And finally the swtch
char does not allow to map the tty to e.g. can345
Can you give my suggestion a try with your hardware?
Regards,
Oliver
>> AFAICS this approach does not solve the problem at it's root.
>> And i doubt this to become a functionality for mainline Linux as it 'reuses'
>> potentially 'dead' options in a different manner ...
>>
>> I would propose to have a table of assignments, e.g. in
>> /etc/slcan-devs
>>
>> /dev/ttyS0 can0
>> /dev/ttyUSB0 can3
>>
>> 1. The slcand may create a file in /var/whatever containing the serial
>> device name "/dev/ttyUSB0" at netdev creation time.
>>
>> 2. Let's say the slcand still creates a 'slc0' netdevice with the
>> ioctl()
>>
>> 3. Write a udev-rule that's invoked when the 'slc*' is created and
>> announced to the system. This udev-rule can look through
>> /etc/slcan-devs and then renames slc0 -> can3 with the ip-tool:
Ah - my original idea :-)
And with the SIOCGIFNAME you always get the created netdev name from the tty
that was missing in this description.
>>
>> ip link set slc0 name can3
>>
>> 4. Remove /var/whatever to be ready for the next slcan device creation
>>
>>
>> That's IMHO the way this slcan 'naming problem' should be handled in
>> the user-space. Setting "stty swtch 4 -F /dev/TTYUSB9" makes the
>> problem a kernel problem but it does not solved the original issue.
>>
>> Regards,
>> Oliver
>>
>> _______________________________________________
>> Socketcan-users mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/socketcan-users
>> _______________________________________________
>> Socketcan-users mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/socketcan-users
>
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
