ModTashtalk: lt0 driver for Linux

[NJRoadfan]

Where is this "support" for LocalTalk in the kernel outside of what is in the AppleTalk stack (which isn't much)? Also does m68k Linux support native Zilog SCC LocalTalk?

 

[dougg3]

It's essentially just the stuff here, I think, with perhaps other references in the other files to LocalTalk stuff as well.

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/appletalk/dev.c
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/if_ltalk.h
• https://git.kernel.org/pub/scm/linu.../linux.git/tree/include/uapi/linux/if_ltalk.h

Also does m68k Linux support native Zilog SCC LocalTalk?

Not that I'm aware. If it did, I'm pretty sure it would show up as another driver that was making use of the LocalTalk stuff here. I think the Mac OS does some pretty...iffy...stuff with taking over the CPU to make sure it never loses anything in the SCC's buffers. Wouldn't be surprised if the actual Linux kernel wouldn't be able to keep up. I could be totally full of crap when I say that, just remembering the problems I dealt with when I used the SCC in my project...

 

[NJRoadfan]

I'd have to look, but I recall MacOS 9 having dedicated drivers for SCC LocalTalk support. Wonder how the ISA cards handled it so well? They have a 1.8Mhz 65c02 and 8k of RAM on them, but so did most Apple I/O cards at the time .

 

[dougg3]

This is a bit of a wild guess, but I would assume the processor on the ISA card is handling some of the tighter timing requirements and buffering stuff a bit. I have a Farallon LocalTalk ISA card and it has a Z80180 processor in addition to the SCC too. It's definitely doing more than just exposing the raw SCC to the ISA bus...

 

[twelvetone12]

For what is worth, I would be very happy to contribute this module to the kernel and possibly some other patches to the AppleTalk stack. I have no idea where to start tho.

 

[dougg3]

For what is worth, I would be very happy to contribute this module to the kernel and possibly some other patches to the AppleTalk stack

I would be happy to help you figure this out (assuming we both have time, haha). I've never actually submitted a brand new driver (I've only done patches to existing drivers) but the overall patch submission process is the same.

I'm guessing they would want you to allocate a new TTY line discipline as a separate commit by itself, for starters, in include/uapi/linux/tty.h.

The part where this might get tricky is this requires changes in multiple subsystems. I'm guessing the TTY people would want the line discipline commit whereas the networking people would want the actual tashtalk module that uses it. Looks like the last time someone added a new one, they submitted the line discipline as a separate individual patch after getting approval on the patch series containing the actual driver that uses it.

Maybe an "RFC" patch of the tashtalk module would be a good first step to get a feel for the networking maintainers' feelings on adding a new LocalTalk driver...I'm sure there's plenty of the process that I don't understand. I can definitely help you with the fun associated with "git send-email" and figuring out who (and what mailing lists) to CC if you're interested.

 

[twelvetone12]

Cool I'm in to try this.
For now I use 29 which is the "test" discipline, then we will see.
At this stage I think these are the next steps:

• I need to polis up the code still and add documentation
• I would like somebody to review it
• Run lint and make it more compatible with the kernel coding style
• I need to study the style guide and make sure the code follows that

I hope they are interested in keeping LocalTalk alive, I think with the hardware we have today there is a sweet spot to use old macs with modern solutions. I will also finish up the LT2USB project to show there is actually something you can plug and it will allow a PC to go localtalk. I intend to make this open source so it is not tied to a company.

Regarding COPS, I'm sincerely surprised it made it so long! AFAIK the cards were impossible to find already 20 years ago and were ISA. But it stayed enough that I could base the TashTalk driver on it

 

[dougg3]

I just got CC'ed this morning on a few kernel patches:

• Removal of the IPDDP driver. I think this is a good thing, because as I recall it interferes with the userspace solution that people actually use.
• Removal of LocalTalk.

 

[tashtari]

Removal of LocalTalk.

Oh no. D:

 

[twelvetone12]

Well I guess I arrived too late then. A bummer, but such is life.

 

[NJRoadfan]

I have zero objection to the removal of IPDDP or whatever that PPP support was for. I don't see the rush to remove LocalTalk support though, considering people are experimenting with it. I really don't want to have to patch the AppleTalk module and recompile..... especially after getting rid of IPDDP (the other reason why I have to recompile modules).

 

[twelvetone12]

I too think IPDDP should go, it interferes with MacIPGW (which works great with modtashtalk btw). Unfortunately I have no voice to object to the removal ok LocalTalk or i would do so.

 

[tashtari]

Can you speak up on the mailing list saying you're about to bring in some code that depends on the LocalTalk code and could they please hold off removing it for at least a short time? Or is that not how this works?

 

[dougg3]

My understanding is this is exactly the time to raise any objections. We should reply (not just on the mailing list, but to the CC list) and say that a new LocalTalk driver is in development.

 

[twelvetone12]

If you think it is doable, I can write an email explaining my work in this driver and my reasoning behind it. I can add the people on the CC list directly when I write to the mailing list?

 

[dougg3]

Unfortunately, writing these messages to the mailing list can be...tricky. Make sure your mail client is set up for plain text only (no HTML). My suggestion would be to import the original message into your mail client, if that's possible, and then click Reply All. That way the discussion is all part of the same thread.

I think the "raw" link on the lore.lernel.org link makes something that resembles an mbox file for import, if I'm not mistaken...

 

[twelvetone12]

ok message sent! I'm not sure if it was ok, will see what happens...

 

[NJRoadfan]

One concern that was brought up in the patch is eliminating calls to the .ndo_do_ioctl callback, which is deprecated. If they decide to keep LocalTalk support, you may have to rewrite function tt_ioctl() to match what modern drivers do. Looks like you use ndo_siocdevprivate for that as the "new" way? See: https://lore.kernel.org/netdev/20210727163024.GA2164561@nvidia.com/T/

Not a big ask considering there are no longer any legacy LocalTalk card drivers left!

This might cover the change, although I've not all that well versed in Linux device driver coding: https://stackoverflow.com/questions...ernel-5-15-and-5-4-0-concerning-ioctl-valid-c

modtashtalk (and the COPS driver for that matter) doesn't support SIOCDEVPRIVATE calls, so I don't know why they would have proposed using ndo_siodevprivate.

 

[twelvetone12]

They already replied, and were very kind! Sincerely I was a bit nervous to to post on the Linux mailing list for the first time
All the stuff they ask is very reasonable, including ndo_do_ioctl, and are things I was thinking of proposing patches later on. The reason I kept stuff like ndo_do_ioctl was to try to stay close to the (working?) COPS driver and then fix things through incremental baby steps.

 

[NJRoadfan]

I did some browsing of the kernel source. Looks like the COPS driver and friends were the only ones using ndo_do_ioctl to do SIOCGIFADDR and SIOCSIFADDR. Looks like these commands are normally reserved for higher level protocols (like TCP/IP) and not directly implemented in network devices. Clearly it was an acceptable hack 20+ years ago, but I can see why they want it removed.