Message-Id: <D4934680-DFB5-471F-893F-32FEA9A6C26C@xhero.org>
Date: Wed, 11 Oct 2023 09:09:02 +0200
From: Rodolfo Zitellini <rwz@...ro.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>,
 Jakub Kicinski <kuba@...nel.org>,
 Netdev <netdev@...r.kernel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-wireless@...r.kernel.org,
 Johannes Berg <johannes@...solutions.net>,
 linux-wpan@...r.kernel.org,
 Michael Hennerich <michael.hennerich@...log.com>,
 Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>,
 "David S . Miller" <davem@...emloft.net>,
 linux-kernel@...r.kernel.org,
 Doug Brown <doug@...morgal.com>
Subject: Re: [PATCH 01/10] appletalk: remove localtalk and ppp support



> Il giorno 10 ott 2023, alle ore 10:15, Arnd Bergmann <arnd@...db.de> ha scritto:
> 
> On Tue, Oct 10, 2023, at 09:10, Rodolfo Zitellini wrote:
>>> Il giorno 9 ott 2023, alle ore 19:29, Arnd Bergmann <arnd@...db.de> ha scritto:
>>> On Mon, Oct 9, 2023, at 18:49, Rodolfo Zitellini wrote:
>>> I can see a few ways this could work out:
>>> 
>>> - add a custom callback pointer to struct atalk_iface to
>>> get and set the address for phase1 probing instead of going
>>> through the ioctl
>> 
>> This was my initial thought, at least for the moment, mostly to keep 
>> netatalk happy and make sure I don’t break other stuff that makes 
>> assumptions on how the address probing worked. There are other bits I 
>> would like to improve, for example tcpdump (which parses correctly 
>> appetalk packets!) is broken in the current implementation.
>> 
>>> - rewrite the probing logic in aarp.c more widely, and improve
>>> the userspace interface in the process by introducing a netlink
>>> interface
>> 
>> This is sorta the “second step” I was planning, I think the logic for 
>> probing could be redesigned and simplified (it also does not work 100% 
>> correctly), and it could be a good chance to improve the interface with 
>> netatalk too.
> 
> Ok, I've adapted my patch now to not actually drop the
> localtalk code for now, and sent that out, I hope that works
> for you. Even if we go with the v1 patch that removes it all,
> you could just as well start with a revert of my patch when
> you add your driver, so in the end it shouldn't make much
> of a difference.

Thank you very much! I will try to make my patch ready to be submitted soon, and I will add the proper reverts if needed.

>>> - Move your entire driver into userspace and go to the kernel
>>> using tun/tap. This has the added benefit of avoiding a lot
>>> of the complexity of the tty line discipline code you have.
>> 
>> We had some discussion too if to just make the lt an userspace stack, I 
>> personally like how it is currently implemented because existing code 
>> can run basically without modification.
>> 
>> I would propose at this stage to change the TashTalk driver to remove 
>> ndo_do_ioctl and to use a custom callback, if this ok.
> 
> It looks like you still need a custom userspace tool to set up
> the uart for your new driver, so my feeling would be that having a
> userspace bridge to implement the localtalk/uart to ethertalk/tap
> driver would actually be nicer for both usability and maintenance.
> 
> It's not something we need to decide now though, and is up to
> you in the end.

I will experiment with this too, as it will require a bit of work to morph localtalk packets to ethertalk/aarp ones, and the code in the kernel has some specialized bits for localtalk here and there.

In any case, many thanks!
Rodolfo

Powered by blists - more mailing lists