Re: [PATCH 01/10] appletalk: remove localtalk and ppp support

[Arnd Bergmann]

On Tue, Oct 10, 2023, at 09:10, Rodolfo Zitellini wrote:
>> Il giorno 9 ott 2023, alle ore 19:29, Arnd Bergmann <arnd@xxxxxxxx> 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.

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

      Arnd