On 11/4/2026 08:51, Craig wrote:
If the main concern here is ongoing maintenance of these Ham Radio
related protocols/drivers, can we pause for a moment on anything as
dramatic as removing from the tree entirely ?
There is a good cohort of capable kernel folks that either are or
were ham radio operators who I believe, upon realising that things
have got to this point, will be happy to redouble efforts to ensure
this code maintained and tested to a satisfactory standard.
Or, alternatively, as a technical community it may be that the Ham
Radio interested folks conclude that out of tree or user space
solutions are a better way forward as others have proposed.
Give us a few days, please, for the word to be put around that we
need to pull ourselves together a bit as a technical group :)
I, for one, really can't imagine pulling an entire network subsytem
out of the kernel without any
knowledge of how/if/when it's used. Like intercontinental radio
networks, global email, ax.25
keyboard-to-keyboard, BBS and other emergency-communication systems
throughout the
world. If you're sure the Internet will never fail, I guess it makes
sense removing all of this
since it's inconvenient to maintain.
Global AX.25 keyboard-to-keyboard on 14.105Mhz
https://qsl.net/kb9pvh/105.html
AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
Global radio email using AX.25
https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
the Earth and Space)
This is all in operation by Amateur Radio ARES emergency
protocols/technologies. This
will not pass the headline test when it comes to Linux detractors.
Most of this is running on Raspberry Pi / Linux 24/7.
If we want to kill all these apps and somehow force them into user space,
it's akin to just switching to Windows - and flounder with the
Microsoft folks
trying to do the same thing.
Your email Craig neatly encapsulates just some of the practical and
ongoing applications of the kernel code in question - I don't think this
is in dispute.
What's pertinent is if we as the ham/amatuer radio community can agree
on whether in tree, out of tree modules, or a userspace device driver
approach make the most sense. If we are to keep code in the kernel in
any form, we as a community need to find someone(s) that have the skills
and bandwidth to keep the in tree code up to date.
I don't think this would be onerous and I have a couple of people in
mind to nudge who may be happy to do so if that proves the right way
forward. At a pinch I could do it, but that'll mean a lot of catching
up. But I think it reasonable that the responsibility here falls to
folks that are closer to the code in question than the wider and
overworked kernel maintainer community.
That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong
case for moving out of the kernel while still providing a way to have
backward compatibility, perhaps this might be the way forward?
In any case, done well, this approach would not kill the apps or force
anything like switching to Windows! :) Great projects like digipi would
be able to continue with minimal changes.
I wonder if a separate thread in linux-hams makes sense to discuss the
various longer term approaches to maintaining these capabilities - I'll
try make time later today to kick one off - such deliberations will be
of less interest to the broader LKML and other lists.
Cheers/73
Hugh
-craig
https://digipi.org/
--
I am slowly moving to [email protected] as my main email address.
If you're using [email protected] please update your address book accordingly.
Thank you :)
