On Oct 25, 2023, at 10:31 PM, Dan Cross
<crossd(a)gmail.com> wrote:
On Tue, Oct 24, 2023 at 10:50 PM John Forecast <john(a)forecast.name> wrote:
Sometime around mid-2022 the Linux kernel
developers decided to remove the DECnet code from the Linux
kernel. Kernel 6.0.x was the last release which included source code for a DECnet
implementation. More
recently, there has been some discussion around removing the code from the Long Term
Support kernels.
These changes mean that the repository I have been maintaining at
<https://github.com/JohnForecast/RaspbianDECnet> can no longer be installed on
recent releases.
Over the past year or so, I have been working on a replacement for this repository with
the following
characteristics:
- Designed to be built as an external kernel module
John, forgive me if this question is obtuse, but I'm curious: is there
any reason this couldn't be hoisted entirely into userspace and built
using TAP/TUN, which would put a (relatively) clean interface between
DECnet and the kernel?
That would deal with the network interface end, but the other end (the API) is sockets,
and I don't think there is a FUSE analog for sockets that lets you implement a socket
address family in user mode. If there were, that might be enough to do what you
describe.
This is why the PyDECnet API is clunky; it needs to handle requests relating to one or
more full duplex data connections, but it's hard to find an elegant POSIX API that
PyDECnet can hook into. The least ugly I have found so far is the one in the T1.1 beta,
which uses pipes or Unix domain sockets to pass DECnet API requests encoded in JSON. It
works, but it certainly isn't transparent the way the DECnet/Linux socket extensions
are.
paul