Re: [PATCH net-next] net: appletalk: remove Apple/Farallon LocalTalk PC support

On Wed, May 11, 2022 at 2:20 AM Doug Brown <[email protected]> wrote:
>
> On 5/9/2022 11:48 PM, Arnd Bergmann wrote:
> > If I understand this correct, this means we could remove all of
> > drivers/net/appletalk/ except for the CONFIG_ATALK Kconfig entry,
> > and also remove net/appletalk/dev.c and a few bits of net/appletalk
> > that reference localtalk device structures and their ioctls, right?
> Yes, I believe so. At that point, would Kconfig get moved to
> net/appletalk instead? (Just wondering out of my own curiosity!)
> > What about appletalk over PPP (phase1 probing in aarp.c) and
> > ARPHRD_LOCALTLK support in drivers/net/tun.c? Are these still
> > useful without localtalk device support?
>
> I don't feel qualified enough to answer those ones definitively, but it
> looks to me like the ARPHRD_LOCALTLK support in net/tun.c could be
> stripped out, because tun_get_addr_len only gets called on a struct
> net_device's type, and stripping out LocalTalk would make that condition
> impossible (I think?)

Right, I came to the same conclusion here.

> The AppleTalk over PPP stuff probably allows Linux to be an AppleTalk
> Remote Access server. I'm not aware of anyone using that capability, (or
> if it even still works) but I would consider it distinct from LocalTalk.

I dug around in the early git history for this one, but I'm also not
sure if this is meant to still work. I see that PPPTALK support was added
to net/appletalk by Alan Cox in linux-1.3.78 (1996), based on the localtalk
support, and it continues to exist there along ethertalk and localtalk.

I also looked at the git history for the pppd user space, and I find no
indication of appletalk ever being supported there, this all looks
IPv4/IPv6 specific. There was support for PPP_IPX until it was
dropped this year (the kernel side got removed in 2018), but never
for PPP_AT.
Adding Paul Mackerras to Cc, he might know more about it.

> I would definitely be happy to test any patches to make sure that
> EtherTalk still works with netatalk afterward!

       Arnd