Linux kernel drops AppleTalk Networking

Nothing has actually been started. Just a discussion opened by @slipperygrey.

A preferred way to do this would be to abstract most of the changes. Netatalk already has the netddp functions defined in netddp.h to partly abstract socket communications. That alone should get afpd, papd, a2boot, and timelord working since they all rely on ATP, which calls netddp_open/close/send/receive. Being an external project originally, macipgw doesn't use it at all.

Oddly, the NBP, RTMP, and ZIP packet handlers in atalkd don't use these abstracted functions, but I don't see why they can't. Of course the comments in the code are minimal to none. The main atalkd handler also doesn't use them, but that code is "here be dragons" and I really hate touching it for fear of something blowing up.

TL;DR: Instead of a ton of ifdefs in the code, focus on routing everything thru netddp.h function calls and putting your entry points (kernel vs. userland ifdef macros) there. This makes code easier to maintain. When I have time, I'll look to see if abstracting the rest of the socket calls in atalkd can be done safely.
 
One of the things I was curious about too is what you thought about using protobuf for the definition for the userspace daemon < - > atalkd/netatalk components. I thought it would be interesting to have a well defined format for it so the daemon side could be swapped fairly easily. This is what I used for the PoC with Prost for the Rust side and nanopb for Netatalk, encoded as varint length delimited + protobuf payload over Unix socks. I use gRPC heavily for work so I am sure you can see the influence bleeding through 😄

Here was a link to the TailTalk userspace daemon using the above style that I cleaned up a little bit that ran the Netatalk demo I took a screenshot of: https://github.com/FeralFirmware/TailTalk/commit/66e2669773047bf0c3ea3323bc7a037d0e3c7b86 Not pretty by any means, but it does work reasonably well for a PoC I think.

I admit that trying to hook to what is a third party userspace daemon though probably isn't super fun for Netatalk maintenance, but I'd love to help out in any way I can to keep this project going regardless of if it uses TailTalk or not.
 
Back
Top