[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7076f95-b25b-3694-1ec2-9b9ff93633b7@schmorgal.com>
Date: Tue, 10 May 2022 17:20:25 -0700
From: Doug Brown <doug@...morgal.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jakub Kicinski <kuba@...nel.org>,
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 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?)
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 would definitely be happy to test any patches to make sure that
EtherTalk still works with netatalk afterward!
Doug
Powered by blists - more mailing lists