[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9cac4fbd-9557-b0b8-54fa-93f0290a6fb8@schmorgal.com>
Date: Mon, 9 May 2022 19:34:04 -0700
From: Doug Brown <doug@...morgal.com>
To: Jakub Kicinski <kuba@...nel.org>, Arnd Bergmann <arnd@...db.de>
Cc: David Miller <davem@...emloft.net>,
Networking <netdev@...r.kernel.org>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Jonathan Corbet <corbet@....net>,
Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH net-next] net: appletalk: remove Apple/Farallon LocalTalk
PC support
On 5/9/2022 10:32 AM, Jakub Kicinski wrote:
> On Mon, 9 May 2022 19:14:42 +0200 Arnd Bergmann wrote:
>> I think however, if we remove this driver, we need to discuss removing the
>> last remaining localtalk driver (CONFIG_COPS) and possibly the localtalk
>> bits in net/appletalk along with it.
> Removing COPS and appletalk makes perfect sense to me (minus what Doug
> has plans to use, obviously).
I also think removing the COPS driver is a great idea. I actually ended
up buying a compatible card in the hopes of working on that driver to
change it to load the firmware through the firmware API, but the
licensing situation with the firmware blobs kind of brought that idea to
a standstill. I would be very surprised if anybody is actually using
LocalTalk ISA cards these days anyway, so it's probably not worth the
effort to maintain it.
There have been a few "modern" LocalTalk interface projects. One is
mine, which I haven't found time to finish, but I was able to get
working in the kernel with a lt0 network interface. I suspect I was the
only one in the last decade to actually use the LocalTalk code in modern
kernel versions, because it was crashing until I fixed a bug involving
too short of a header length being allocated. There's another more
recent LocalTalk project called TashTalk [1]. A kernel driver could be
developed for it using serdev or a tty ldisc, but all of the current
development seems focused on the userspace side.
With that in mind, I personally wouldn't be sad to see the entire
LocalTalk interface support stripped from the kernel, as long as
EtherTalk support can remain. There is still a decent sized community of
users who are using it to talk with classic Macs using netatalk 2.x.
So most of the stuff in net/appletalk is still relevant today for us.
Might as well remove CONFIG_IPDDP too. It actually -interferes- with the
current way that people do MacIP gateways through userspace with macipgw
[2]. I'm not aware of anyone actually using the kernel's implementation.
Doug
[1] https://github.com/lampmerchant/tashtalk
[2] https://github.com/jasonking3/macipgw#kernel
Powered by blists - more mailing lists