forms of validation on incoming frames I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code for its AX.25 stack. This is still excellent software that is maintained. I also use Linux as a netrom node for said BBS with real radio ports and internet connectivity to out of town nodes using the ax25ipd/netromd that both use kernel stacks.
73 de Chris KQ6UP Thanks, Chris Maness Thanks, Chris Maness -Sent from my iPhone On Fri, Apr 10, 2026 at 4:53 PM Chris Maness <[email protected]> wrote: > > I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code for its > AX.25 stack. This is still excellent software that is maintained. I also > use Linux as a netrom node for said BBS with real radio ports and internet > connectivity to out of town nodes using the ax25ipd/netromd that both use > kernel stacks. > > 73 de Chris KQ6UP > > Thanks, > Chris Maness > -Sent from my iPhone > > > On Fri, Apr 10, 2026 at 4:38 PM Hugh Blemings <[email protected]> wrote: >> >> >> 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 :) >> >> -- Thanks, Chris Maness
