Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[David Ranch <linux-hams@trinnet.net>]

Hello Hugh,

<snip>

> There's also been some very good points raised in that thread by hams 
> around whether it makes sense to move the implementation into 
> userspace or to out of tree kernel code. Both can be done in such a 
> way as to cause little to no impact from the actual application code 
> that makes use of the protocols.

I've done a little bit of research on the LD_PRELOAD concept and it 
seems that one major gap here is compiling those tools and their 
dependencies.  Specifically, if the AX25 headers are removed from the 
kernel tree, some if not all of these libraries and/or programs will 
file to compile.  The key dependencies consist of:

    - the libax25 library compiled which requires the AX.25 kernel headers
       - My preferred source (more up to date): 
https://github.com/ve7fet/linuxax25
            or
       - Original AX.25 userland repos that are a bit stale: 
https://linux-ax25.in-berlin.de/wiki/Main_Page


To solve the maintenance issue, there once was an ARDC grant ( 
https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/ 
) to have someone take on this responsibility but the person who 
originally accepted the grant, backed out and that need remains 
unfulfilled.   I have also considered proposing a grant to rewrite the 
libax25 code to offer both in-kernel support but also offer the ability 
to translate requests to a remote AGW/PE stack and remove any in-kernel 
AX.25 code.  That could be an excellent alternative but the current 
defacto AGW API interface is limiting and either needs to be extended or 
a parallel control interface needs to be implemented.


> If the consensus is that trying to keep the drivers in thee tree up to 
> date is the way ahead I'm happy to put my hand up to do this if no one 
> else is so inclined - I've a couple friends I can bug to help me get 
> back up to speed.
> But I'm also mindful there are other hams that have been more recently 
> involved in kernel work, so am going to give them a gentle nudge 
> offline too :)

Until some *real* options exist, I would dearly appreciate if you'd be 
willing to take this role up and I (as well as I'm sure others) would be 
happy to help on the testing side.  It should also be noted that Dan 
Cross's comprehensive post did highlight some keys points as well.  The 
Linux AX.25 v2.1 stack is behind the times as the AX.25 v2.2 spec added 
several valuable improvements.  A few userland AX.25 stacks such as from 
WB2OSZ Direwolf, G8BPQ LinBPQ, VE4KLM JNOS, etc. have added AX.25 v2.2 
support, FX.25 FEC support, etc. It would be great to see Linux natively 
add them too but maybe Linux go even further?  Ideas like adding native 
Flexnet routing support would be an excellent addition.

Ultimately, my preference of in-linux support is all the fantastic 
routing flexibility that UNIX is naturally good at.  I suppose that 
userland could do this too but when you might be running multiple AX.25 
userland programs talking to another Userland program acting as a 
router, I imagine things will get complicated for totally different reasons.


--David
KI6ZHD
Maintainer of the Linpac packet terminal program
Silicon Valley 44-Net AMPR coordinator
Maintainer of the Linpac and AX25mail-tools programs
Long time Linux advocate since the linux-1.2 days including being a long 
run IP Masquerade HOWTO maintainer
Maintainer of other many Linux-centric documentation programs like the 
TrinityOS HOWTO, Packet Radio on Raspberry Pi HOWTO, etc.