SMP fix for 6pack driver

Drivers really only work well in SMP if they actually can be selected. This is a leftover from the time when the 6pack drive only used to be a bitrotten variant of the slip driver.

 Kconfig |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-cvs/drivers/net/hamradio/Kconfig
===================================================================
@@ -17,7 +17,7 @@
 
 config 6PACK
 	tristate "Serial port 6PACK driver"
-	depends on AX25 && BROKEN_ON_SMP
+	depends on AX25
 	---help---
 	  6pack is a transmission protocol for the data exchange between your
 	  PC and your TNC (the Terminal Node Controller acts as a kind of

Such a limitation has never existed as far as I can tell; the sole limitation is to a single TNC per RS-232 interface. Daisy chaining multiple TNCs per interface is still not supported. If you run out of serial interfaces using for example USB serial interfaces should work just fine.

(For dare devils, attaching a remote 6pack TNC via for example ssh sort of works also ;-)

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Ralf,
What is lacking that would allow 6pack TNC's to be daisy chained? By doing so we would be able to use a single serial port to support multiple TNC's I have the documentation on how to wire the hardware and that is no big deal.

I have USB running on a laptop, it works well most of the time but at times when the machine boots one or other ports generates the "trying to synch tnc" message. The serial port always works.

I think that at times the USB part is slow to get totally initialized so I have gone in and added sleeps to slow things down a bit at init.

Ahh a subversive TNC to spy on a remote network???

Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Well, by the time I was writing that driver I didn't have a 6pack TNC at all, so I wrote a 6pack TNC emulator that is capable of simulating a single TNC. I still don't have multiple TNCs, unfortunately, so I'm planning on extending that emulator for my work :-)

You could try EB6EBU's m6pack which is an application level solution to the problem. I'm undecieded, maybe it's even preferable over a kernel solution.

Mine seems to be ok as long as the machine survives plugging in the USB device and open()ing the device file. Never really looked into it, blaming the driver for now.

It's a strategy that allows attaching the TNC to any UNIX machine, even without AX.25 support. It's a hack but I was playing with it for a while when I ran out of interfaces.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

That could be VERY userful... Any more details available?

Thanks,
Bill - WA7NWP

6pack is implemented as a line discipline, so any tty, including a pseudo tty can be turned into a 6pack interface. So all it takes is a network connection, let's say through ssh, an application on the remote side that transfers data on the remote side between that connecton and the /dev/tty... character device to which the TNC is connected. Same thing also on the local side, just between the pseudo-tty and the filedescriptor. Pretty much a nobrainer to implement but latency could be a slight problem.

(And if you don't truncate the cc list of email you even have a chance to getting answers in time ...)

Ralf

Hi all,

Has someone worked on making mkiss driver compatible with smp kernel ?

73 de Bernard, f6bvp

Hi,

I tried to apply Ralf's patch to mkiss.c without success.

Did someone succeed ?

I would like very much to test this version with 2.6.11mdksmp kernel.

Could someone send me privately the full modified mkiss.c ?

73 de Bernard, f6bvp

-----------------
From: Ralf Baechle <[email protected]>
Date: Thu Jul 07 2005 - 22:27:01 EEST

This is an almost complete rewrite of the mkiss driver trying to fix all the issues this driver was having such as SMP, preemption etc. Basically this makes this driver more of a descendant of PPP than of the old slip code, as it used to be.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

 mkiss.c | 1052 
++++++++++++++++++++++++++++++----------------------------------
 1 files changed, 507 insertions(+), 545 deletions(-)

Index: linux-cvs/drivers/net/hamradio/mkiss.c
===================================================================

the patch is only for 2.6.12.x kernels

Stephen - vk3heg

Hi Stephen,

Thank you.

But I tried to apply it on different mkiss.c up to the last kernel 2.6.12.2 without success.

I really need some more info about the source of mkiss.c repository or to receive the full patched mkiss.c

73 de Bernard, f6bvp

-----------

Or more accurately, it should work for 2.6.12-rc4 or newer. The sympthom for kernels older than this is this warning:

CC drivers/net/hamradio/mkiss.o
drivers/net/hamradio/mkiss.c: In function `ax_bump':
drivers/net/hamradio/mkiss.c:267: warning: implicit declaration of function `ax25_type_trans'

The warning unfortunately is the sympthom of a serious problem ...

Ralf

Hmm, it's been this way for quite a while, and users can still build w/ CONFIG_CLEAN_COMPILE=n. So, obligatory questions... I suspect it was orignally marked broken for cli/sti abuse, quick grep suggests this has been dealt with. Have the reasons it was marked broken been addressed?

thanks,
-chris

Obviously, otherwise I'd not send such a patch :-) cli/sti abuse etc. 6pack was pretty much 2.0 or even pre-2.0 code before I started.

Somehow I managed to strip the BROKEN_ON_SMP patch bit from the last set of 6pack patches I sent, it was supposed to be in there.

I got a similar near-rewrite for mkiss in the queue but that certainly isn't something for -stable, way too large.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

;-)

Thanks Ralf, I've no issue with this, esp. since it's so trivial. -chris

applied