all the existing Linux packet applications break.  Maybe if a new libax25 library was created that could redirect all those calls to something in userland, that would work but that doesn't exist today.  By also moving out of the kernel, we loose most of the advanced routing abilities in playing around with AX25/Netrom/Rose, etc. It should be possible to make a usermode program that handles socket calls made by other programs. I.e. you continue to use a socket interface but the protocols are not in the kernel but in that user program. Solutions like this are used for many exotic services that cannot live in the kernel for maintenance reasons. (although for technological reasons they should be in the kernel) kernel".  If we did that for say IPv4, IPv6, etc... that would dramatically reduce the functionality of Linux as it stands today. So much would need to change to accomodate a wholesale shift to Userland. Well of course it has been a discussion since (before) linux was first developed.  The monolithic vs microkernel discussion. However, you should not compare it to IPv4 or IPv6. The issue is not whether network protocols technologically belong in the kernel, but whether it is sustainable to keep protocols that are used by about 100 users out of a Linux user population of billions can be kept in the kernel and survive every restructuring of the kernel without being damaged beyond usability because people are making changes and don't (because they cannot) test them in real use. Apparently not.  So it is better to go for a solution that works. I have been running my version of NET on top of the kernel SCC card driver for quite some time, and there were no issues like this.  It had a separate IP address and was connected to the kernel IP stack via tun/tap. Of course that is not a solution for socket applications using AX.25 but something similar could be done. Rob