On Tue, Oct 10, 2023, at 09:10, Rodolfo Zitellini wrote:

quoted

Il giorno 9 ott 2023, alle ore 19:29, Arnd Bergmann [off-list ref] 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.

quoted

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

quoted

- 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