netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).