Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d
MIME-Version: 1.0
Message-Id: <3cb4bb96-1651-4179-9c32-507937282d7d@app.fastmail.com>
In-Reply-To: <790BA488-B6F6-41ED-96EF-2089EF1C043B@xhero.org>
References: <20231009141908.1767241-1-arnd@kernel.org>
 <790BA488-B6F6-41ED-96EF-2089EF1C043B@xhero.org>
Date:   Mon, 09 Oct 2023 19:29:11 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Rodolfo Zitellini" <rwz@xhero.org>,
        "Arnd Bergmann" <arnd@kernel.org>
Cc:     "Jakub Kicinski" <kuba@kernel.org>,
        Netdev <netdev@vger.kernel.org>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        linux-wireless@vger.kernel.org,
        "Johannes Berg" <johannes@sipsolutions.net>,
        linux-wpan@vger.kernel.org,
        "Michael Hennerich" <michael.hennerich@analog.com>,
        "Paolo Abeni" <pabeni@redhat.com>,
        "Eric Dumazet" <edumazet@google.com>,
        "David S . Miller" <davem@davemloft.net>,
        linux-kernel@vger.kernel.org, "Doug Brown" <doug@schmorgal.com>
Subject: Re: [PATCH 01/10] appletalk: remove localtalk and ppp support
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Oct 9, 2023, at 18:49, Rodolfo Zitellini wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>=20
>> The last localtalk driver is gone now, and ppp support was never fully
>> merged, so clean up the appletalk code by removing the obvious dead
>> code paths.
>>=20
>> Notably, this removes one of the two callers of the old .ndo_do_ioctl=
()
>> callback that was abused for getting device addresses and is now
>> only used in the ieee802154 subsystem, which still uses the same tric=
k.
>>=20
>> The include/uapi/linux/if_ltalk.h header might still be required
>> for building userspace programs, but I made sure that debian code
>> search and the netatalk upstream have no references it it, so it
>> should be fine to remove.
>>=20
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hi!
> I=E2=80=99ve been working on a new LocalTalk interface driver for the =
last=20
> couple months, do you think it would be possible to at least postpone=20
> the removal of LT a bit?
>
> It is a driver for an open source device called TashTalk=20
> (https://github.com/lampmerchant/tashtalk), which runs on a PIC micro=20
> that does all the LT interfacing, and communicates back via serial to=20
> the host system. My driver is relatively simple and works very well=20
> with netatalk 2.2 (which is still maintained and still has support for=20
> AppleTalk). The driver is basically complete and trsted and I was=20
> preparing to submit a patch.
>
> Still having LocalTalk in my view has many advantages for us=20
> enthusiasts that still want to bridge old machines to the current worl=
d=20
> without modifications, for example for printing on modern printers,=20
> netbooting, sharing files and even tcp/ip. All this basically works ou=
t=20
> of the box via the driver, Linux and available userspace tools=20
> (netatalk, macipgw).
>
> The old ISA cards supported by COPS were basically unobtanium even 20=20
> years ago, but the solution of using a PIC and a serial port is very=20
> robust and much more furure-proof. We also already have a device that=20
> can interface a modern machine directly via USB to LocalTalk.
>
> The development of the TashTalk has been also extensively discussed on=20
> thr 68KMLA forum=20
> (https://68kmla.org/bb/index.php?threads/modtashtalk-lt0-driver-for-li=
nux.45031/)
>
> I hope the decision to remove LocalTalk can be reconsidered at least=20
> for the time being so there is a chance to submit a new, modern device=20
> making use of this stack.

Nothing is decided, I'm just proposing my patch as a cleanup
for now. It would be nice to still drop the ndo_do_ioctl function
though, at least in some form. When your driver actually makes
it into the kernel, you can find a different method of communicating
the address between the socket interface and the device driver.

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

- rewrite the probing logic in aarp.c more widely, and improve
  the userspace interface in the process by introducing a netlink
  interface

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

      Arnd