Hello Robert and Stephen, i was looking into slcan.c and the patches introducing the SWTC character:
--- 8< --- snip! --- r1170 | hartkopp | 2010-04-16 21:39:09 +0200 (Fr, 16. Apr 2010) | 6 Zeilen Added possibility to force the slcan driver to use a specific device number when set via SWTC char (e.g. with stty). See thread https://lists.berlios.de/pipermail/socketcan-users/2010-April/001378.html Provided by Stephen Hellriegel <[email protected]> So far this change only applies for Kernels < 2.6.32 ... --- 8< --- snip! --- I tend to bring the slcan.c driver into mainline within the upcoming net-next cycle intended for 2.6.38. For that reason, i need to clarify the usage of the SWTC character. Please correct me, if i'm wrong: The SWTC charater is set for the selected tty (e.g. /dev/ttyUSB4) via stty in userspace to ensure in the attach IOCTL syscall to come up with the 'wanted' CAN netdevice name (e.g. can3) directly. Right? If so, my question would be, how you know which SWTC char to set in which tty? Regards, Oliver On 15.04.2010 20:47, Robert Haddon wrote: > > 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 _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
