Since many on this group have the peculiar knowledge on AX.25, on amateur packet radio and related stuff, it could be effective and proficient to re-compact the efforts to support, repair, improve and revamp the linux kernel, the NET/NOS and so on.
The problem with code in the kernel is that it is very difficult to get any improvements available to the user. Assuming that not everyone wants to compile their own custom kernel from source, you need to get the improvements implemented in the standard kernel and then you have to wait until the distribution(s) of choice add this new fixed kernel into their distribution. Then you have to wait until this distribution is widely used by the users.
This can easily take a year, maybe more! And when you discover problems or want to make additions the cycle starts again. Worse: when others make changes and break things, it takes a long time before this impacts users and then again a long time to fix it.
So the approach really should be to take the stuff out of the kernel. Or maybe move it into an indepently developed loadable kernel module, maybe via dkms or so.
Rob
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
On 18.03.2019 22:32, Rob Janssen wrote:
Since many on this group have the peculiar knowledge on AX.25, on amateur packet radio and related stuff, it could be effective and proficient to re-compact the efforts to support, repair, improve and revamp the linux kernel, the NET/NOS and so on.
The problem with code in the kernel is that it is very difficult to get any improvements available to the user. Assuming that not everyone wants to compile their own custom kernel from source, you need to get the improvements implemented in the standard kernel and then you have to wait until the distribution(s) of choice add this new fixed kernel into their distribution. Then you have to wait until this distribution is widely used by the users.
This can easily take a year, maybe more! And when you discover problems or want to make additions the cycle starts again. Worse: when others make changes and break things, it takes a long time before this impacts users and then again a long time to fix it.
So the approach really should be to take the stuff out of the kernel. Or maybe move it into an indepently developed loadable kernel module, maybe via dkms or so.
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yes... now only if we can find some developers who understand the Linux kernel undo the damage! Any takers?
--David KI6ZHD
On 03/18/2019 04:38 PM, Marius Petrescu wrote:
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
This might reach more relevant people on the Linux-hams list.
David, a question. What happens to things like pseudo tty and ax25ipd if ax25 is removed from the kernel?
Ray vk2tv
On 19/3/19 11:23 am, David Ranch wrote:
Yes... now only if we can find some developers who understand the Linux kernel undo the damage! Any takers?
--David KI6ZHD
On 03/18/2019 04:38 PM, Marius Petrescu wrote:
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
The PTS and PTY systems aren't related to AX.25 so they will continue to work. Ax25ipd and all other ax25, netrom, rose, and all other associated libraries, applications, and tools using those protocols will stop working. Failures have already started happening for some use-cases already and that's why people are recommending to revert to old kernels that don't have the breakage. That helps ax25/netrom/rose needs but you loose all other bug fixes, security fixes, new hardware support, etc.
--David KI6ZHD
On 03/18/2019 05:55 PM, vk2tv wrote:
This might reach more relevant people on the Linux-hams list.
David, a question. What happens to things like pseudo tty and ax25ipd if ax25 is removed from the kernel?
Ray vk2tv
On 19/3/19 11:23 am, David Ranch wrote:
Yes... now only if we can find some developers who understand the Linux kernel undo the damage! Any takers?
--David KI6ZHD
On 03/18/2019 04:38 PM, Marius Petrescu wrote:
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Thanks David.
We've lost (losing) bragging rights about ax25's tight integration with the Linux kernel, and all the reasons why I ditched Windows in favour of Linux for my packet radio needs back in 1996.
Ray vk2tv
On 19/3/19 12:13 pm, David Ranch wrote:
The PTS and PTY systems aren't related to AX.25 so they will continue to work. Ax25ipd and all other ax25, netrom, rose, and all other associated libraries, applications, and tools using those protocols will stop working. Failures have already started happening for some use-cases already and that's why people are recommending to revert to old kernels that don't have the breakage. That helps ax25/netrom/rose needs but you loose all other bug fixes, security fixes, new hardware support, etc.
--David KI6ZHD
On 03/18/2019 05:55 PM, vk2tv wrote:
This might reach more relevant people on the Linux-hams list.
David, a question. What happens to things like pseudo tty and ax25ipd if ax25 is removed from the kernel?
Ray vk2tv
On 19/3/19 11:23 am, David Ranch wrote:
Yes... now only if we can find some developers who understand the Linux kernel undo the damage! Any takers?
--David KI6ZHD
On 03/18/2019 04:38 PM, Marius Petrescu wrote:
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
All ideas are good, including that to involve the participation of 'linux-ham', other interested groups, single skilled hams, etc.
Then having a site in which it is possible to download single patches, single patched modules, or better (for me) a packaged compiled kernel+modules ready for installation should be the maximum reaction for testing implied stuff. May be that the above may benefit and cure in some way the actual procedures of official developer's kernel group...
73 and ciao, gustavo i0ojj
On 03/19/2019 12:38 AM, Marius Petrescu wrote:
Just an observation: It is possible to recompile just a kernel module. Get the kernel source, extract the module, patch, compile and load. If it works, replace the default one with it.
Not for the faint hearted, but it is an option.
Marius, YO2LOJ
On 18.03.2019 22:32, Rob Janssen wrote:
Since many on this group have the peculiar knowledge on AX.25, on amateur packet radio and related stuff, it could be effective and proficient to re-compact the efforts to support, repair, improve and revamp the linux kernel, the NET/NOS and so on.
The problem with code in the kernel is that it is very difficult to get any improvements available to the user. Assuming that not everyone wants to compile their own custom kernel from source, you need to get the improvements implemented in the standard kernel and then you have to wait until the distribution(s) of choice add this new fixed kernel into their distribution. Then you have to wait until this distribution is widely used by the users.
This can easily take a year, maybe more! And when you discover problems or want to make additions the cycle starts again. Worse: when others make changes and break things, it takes a long time before this impacts users and then again a long time to fix it.
So the approach really should be to take the stuff out of the kernel. Or maybe move it into an indepently developed loadable kernel module, maybe via dkms or so.
Rob
-
'Gustavo Ponza' -
David Ranch -
Marius Petrescu -
Rob Janssen -
vk2tv