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

Hi All,

Just to note in this thread (top posting as it's a bit orthogonal to the 
rest of this discussion) that events have preceeded us somewhat here

A patch just recently submitted removes the AX25, NETROM and ROSE code 
from the kernel moving it to the mod-orphan sub tree of netdev

https://lore.kernel.org/netdev/[email protected]/T/#u

A shame but perhaps inevitable - but I think we have a good plan 
unfolding to both take care of medium term maintenance of the kernel 
code (in tree or out as it may be) as well as a move to userspace in the 
longer term.

For the benefit of the netdev readership - we had a thread over in 
linux-hams on this but that may not have been visible to folks in 
netdev.  TL;DR: we think we have a way forward but appreciate this may 
not be quick enough to meet the requirements/concerns put forward

If we can delay removal, that'd be grand, but appreciate that moment may 
have passed.

Cheers/73
Hugh
VK3YYZ/AD5RV


On 20/4/2026 02:18, Steve Conklin wrote:
> On Sun, Apr 19, 2026 at 4:36 AM Hugh Blemings <[email protected]> wrote:
>> HI All,
>>
>> On 19/4/2026 14:01, Stuart Longland VK4MSL wrote:
>>> On 19/4/26 05:28, Dan Cross wrote:
>>>> [Top-posting to make meta-commendary]
>>>>
>>>> I wonder if other folks have thoughts, here? It doesn't bode well that
>>>> the discussion hasn't progressed. 🙁
>>> I haven't had a chance to fully review what you've posted… there was a
>>> lot of historical information in there including detail on the
>>> protocols in question.  I've earmarked it to go through closely
>>> however. (e.g. I had heard of "ROSE" but never seen a spec for it.)
>>>
>>> My situation was wanting a library that I could use to do AX.25
>>> networking from userspace without having applications having to
>>> elevate to `root` to achieve it.  There was also a maintenance
>>> concern.  Rather than try and work out the AX.25 kernel stack, I opted
>>> to instead build my own.
>>>
>>> Instructive, but difficult as the documentation is sketchy in places.
>>>
>>> My implementation was written in Python 3.5+ for ease of development.
>>> Probably not the best option, but it got the job done.  `aioax25`
>>> allowed me to deliver a project for an emergency comms group and
>>> provides a reasonable foundation for simple tasks.  The stack is also
>>> portable to other platforms.  (I mostly only care about Linux and
>>> *BSD, but well written software should work elsewhere too.  Apparently
>>> it works fine on Apple MacOS X.)
>>>
>>> A userspace AX.25 daemon which implements the stack would seem to be
>>> the best course of action, but the elephant in the room is what the
>>> API would look like.
>>>
>>> The only thing I've seen close to achieving something like that would
>>> be the AGWPE protocol, however the author of that AX.25 stack has
>>> categorically stated that he "owns" that protocol.  I don't feel like
>>> going to court to argue copyright of interfaces for the sake of a hobby.
>>>
>>> The AGWPE protocol is also very limiting: a lot of fields in the AX.25
>>> frame are not accessible via this protocol, either for reading or
>>> setting.  Want to use the two reserved bits to signal something in a
>>> custom protocol?  Too bad.
>>>
>>> I was therefore pondering a "stream"-like protocol using KISS-style
>>> framing (to re-use existing code).  The frames would serve as an RPC
>>> mechanism for implementing something like the `libax25` API, exposing
>>> the same functionality and allowing an application to interact with
>>> the AX.25 stack without having to implement the whole protocol (as
>>> they'd have to do with KISS).
>>>
>>> Client applications could connect either via Unix domain sockets or TCP.
>>>
>>> You mention the performance hit of crossing the kernel/user-space
>>> boundary… I think Direwolf experimentally can work as high as
>>> 38400bps. A turn-of-the-century desktop PC was easily able to keep up
>>> with that for PPP links (with `pppd` running in userspace). ARMv7
>>> single board computers made 15 years later can deliver similar
>>> performance.  I don't think this will be much of a bottleneck in
>>> practice.
>>>
>>> I think userspace is the right way forward given the niche use case here.
>> Apologies, I kicked off this thread and life intervened a bit and have
>> only now had a chance to get back to read through the excellent
>> discourse since.
>>
>> I did have one off list conversation about this which was similarly
>> leaning towards a well managed/discussed shift to a userspace approach.
>> The individual in question has had quite a lot of both ham radio and
>> FOSS experience - I'll give them a nudge and see if they would be
>> willing to weigh in here too as I think they'd add a lot to the thread.
>>
>> I wonder if anyone on list feels they have the right skills to put
>> together the shim/compatibility library that would be needed to allow
>> the kernel code to be removed?  Seems like that might be the next thing
>> to explore ?
>>
>> Hoping things settle down a bit and will be able to contribute more to
>> ongoing discussion
>>
>> vy 73
>> Hugh
>> VK1YYZ/AD5RV
>>
>>
>>
>> --
>> 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 :)
>>
>>
> Hi all,
>
> I'm another former maintainer who has been less active in the FOSS
> hamm community for a while. Thanks for all the history, and it's been
> great to see familiar names and callsigns again.
> /wave
>
> My personal take is that moving to userspace is the right long-term
> goal. As for deciding the exact form that takes, this thread is a good
> start.
>
> I'd like to make an offer for a long-term home for these components.
>
> I'm a director at ORI (Open Research Institute), and  ORI could be a
> home for these. We're a project-based, completely open and volunteer
> nonprofit focused on ham radio and communications. We have volunteers
> with FOSS and ham radio experience, and we're already set up with a
> GitHub org, slack chat, and the infrastructure to manage projects.
>
> https://www.openresearch.institute/
> https://www.openresearch.institute/your-project-is-welcome/
>
> Anyone who currently maintains or has an interest in this is welcome
> to participate there.
> I personally volunteer to help move development infrastructure to ORI,
> if that's the wish of the community.
>
> Steve Conklin AI4QR
>
-- 
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 :)