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
