Stephen Hellriegel wrote:
> This patch uses the device prefix "can" instead of "slc". A binary library
> we paid for has "can" hardcoded as the prefix of the CAN devicename; "slc"
> breaks it.
> Just search for the edit at slcan.c line 753 in the patch and you will see
> where you can change can back to slc if you are really fond of the slc prefix
> for any reason.
>
> If not, I would love for the default to be can instead of slc, to be
> compatible with other interfaces!
Hello Stephen,
you are right! I also thought about creating canX instead of slcX ... will
change that. But first read the stuff below, if it makes sense to stay on this
naming scheme.
> +/*
> + * By default, do not turn on SLC_CHECK_TRANSMIT
> + * when a slcan device transmits into an unconnected network,
> + * the transmit timeout causes a kernel panic, this behaviour
> + * should be at the choice of the user.
> + */
> +
> +#if 0
> #define SLC_CHECK_TRANSMIT
> +#endif
> +
You mean, that the slcan device does not send any reply when it's CAN
controller doesn't get the CAN frame onto the bus, right?
If so, it would be ok for me also.
The slcan stuff *is* low-cost hardware, and running any kind of acknowledges
seems always to lead into problems.
---
Coming to stty swtch ...
> The following patch file enables a user to perform the following:
> Choose which device instance number you are going to get for a slcan port.
> This is really handy if you have 4 or more 1mbit slcan interfaces that come
and go asynchronously in a Linux system...
>
> #Say you want to kick the CAN on /dev/TTYUSB9 as device can4
> stty swtch 4 -F /dev/TTYUSB9
> #now call slcand as normal
> ifconfig can4 up
>
>
> Presto, no hunting around to figure out which "slc" or "can" number the call
to slcand came up on.
>
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:
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
