From: Arnd Bergmann <arnd@arndb.de>
To: Doug Brown <doug@schmorgal.com>
Cc: Jakub Kicinski <kuba@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
David Miller <davem@davemloft.net>,
Networking <netdev@vger.kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Jiapeng Chong <jiapeng.chong@linux.alibaba.com>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH net-next] net: appletalk: remove Apple/Farallon LocalTalk PC support
Date: Tue, 10 May 2022 08:48:17 +0200 [thread overview]
Message-ID: <CAK8P3a1AA181LqQSxnToSVx0e5wmneUsOKfmnxVMsUNh465C_Q@mail.gmail.com> (raw)
In-Reply-To: <9cac4fbd-9557-b0b8-54fa-93f0290a6fb8@schmorgal.com>
On Tue, May 10, 2022 at 4:34 AM Doug Brown <doug@schmorgal.com> wrote:
>
> 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.
Thanks for all the background information!
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?
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?
Arnd
next prev parent reply other threads:[~2022-05-10 6:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 15:01 [PATCH net-next] net: appletalk: remove Apple/Farallon LocalTalk PC support Jakub Kicinski
2022-05-09 17:14 ` Arnd Bergmann
2022-05-09 17:32 ` Jakub Kicinski
2022-05-10 2:34 ` Doug Brown
2022-05-10 6:48 ` Arnd Bergmann [this message]
2022-05-11 0:20 ` Doug Brown
2022-05-11 8:23 ` Arnd Bergmann
2022-05-12 18:11 ` James Carlson
2022-05-12 19:21 ` Arnd Bergmann
2022-05-12 19:28 ` Doug Brown
2022-05-11 12:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a1AA181LqQSxnToSVx0e5wmneUsOKfmnxVMsUNh465C_Q@mail.gmail.com \
--to=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=doug@schmorgal.com \
--cc=edumazet@google.com \
--cc=jiapeng.chong@linux.alibaba.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).