> Il giorno 10 ott 2023, alle ore 10:15, Arnd Bergmann <arnd@xxxxxxxx> 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@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. 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
