Oliver, Regarding the naming of canX or slcX interfaces
We tried a method that was essentially what you described, and several other variations, but they didn't work. We discovered that this problem cannot be solved in userspace, even with the best udev wizardry. The problem with your mapping table, e.g. in /etc/slcan-devs: /dev/ttyS0 can0 /dev/ttyUSB0 can3 is that the kernel names on the left cannot be predicted when the devices come and go in an uncontrolled order. Udev naming rules affect userspace names only, but under the covers when the kernel is plumbing netdevs, it still uses the kernel name for devices. We verified this with some debug print statements and saw all our wonderful udev rules being completely circumvented. ________________________________________ From: [email protected] [[email protected]] On Behalf Of Oliver Hartkopp [[email protected]] Sent: Thursday, April 15, 2010 10:40 AM To: Stephen Hellriegel Cc: [email protected] Subject: Re: [Socketcan-users] slcan.c patch which supports stty flag to tell which can# (or slc#) you want the driver to plumb 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 _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
