kernel repositories & kernel swapping
bigpup's post, viewtopic.php?p=23542#p23542 reminded me of the difficulty I had trying to find repos of kernels when writing my previous post on the same thread. And, of course, I missed 
the main repo bigpup provided a link to which is http://distro.ibiblio.org/puppylinux/huge_kernels/. The two I mentioned are https://archive.org/download/Puppy_Linux_Huge-Kernels/ and https://rockedge.org/kernels/. peebee also publishes kernel packages. https://sourceforge.net/projects/lxpup/ ... e-kernels/. Of course, you'll find links to other kernels on this thread. But, if you discover any which have been missed, take the time to post about them.
bigpup's post above discusses using the application for swapping kernels which is built into many recent Puppies. There may be an application floating around if your Puppy doesn't have one builtin. Please provide a link if you find it. I always do it manually using the method detailed at the bottom of this post: https://oldforum.puppylinux.com/viewtop ... 0#p1057910.
There are two main reasons for swapping kernels. A different kernel may support hardware which your current kernel doesn't. And newer kernels may be patched against new or newly discovered malware. On the other hand, to reduce kernel compilers' workload and the size of kernels packages, drivers for old hardware may have been left out to make room for the drivers needed by newer hardware. Hence, the 'rule of thumb': "New Kernels for New Computers; Old Kernels for Old Computers." However, take that with a 'grain of salt' or a 'dollop' of Ketchup whichever you prefer. Usually the quickest way to find out is to try.
When trying, remember that to communicate with hardware, kernels need both drivers and firmware. Drivers are compiled for kernels and come as part of the "hugh-kernel" package. Firmware may not be as firmware is not kernel specific. AFAIK, gyrog has published the most complete and up-to-date package, https://www.mediafire.com/folder/k2j223jzddy9x/firmware; Ozsouth a relatively recent and much smaller package, https://archive.org/download/Puppy_Linu ... an2020.sfs. So has peebee, https://sourceforge.net/projects/lxpup/ ... e-kernels/
Like drivers (zdrv.sfses), firmware (fdrv.sfses) have to be named consistent with the Puppy with which they are to be used: e.g., fdrv_fossapup64-9.5.sfs with puppy_fossapup64-9.5.sfs.
I believe there used to be a 'firmware-cutter' application to remove those files not required by your computer. But I can't find it. However, once you know what firmware you actually need, you can rebuild the fdrv.sfs to only contain it. Some remastering applications offer that option.
A couple of last thoughts for those new to 'kernel swapping'. You can use 64-bit kernels with 32-bit operating systems; but not vice-versa.
Kernels compiled for 'slackos' are different from those compiled for 'ubuntu or debian' 64-bit Puppys. When Slackware developed 64-bit versions it added three folders to hold 64-bit libraries, /lib64, /usr/lib64 and /usr/local/lib64. Debian/Ubuntu, however, chose to place 64-bit libraries in /lib/x86_64-linux-gnu; /usr//lib/x86_64-linux-gnu; and /usr/local/lib/x86_64-linux-gnu. Ubuntu and debian-based puppys, however, can not 'read' those folders. As a work-around, under ubuntu and debian puppys, 64-bit libraries are located in /lib, /usr/lib and /usr/local/lib with /lib/x86_64-linux-gnu; /usr//lib/x86_64-linux-gnu; and /usr/local/lib/x86_64-linux-gnu being, respectively, symbolic links to those folders. So, the general consensus is that neither kernels nor applications compiled for 64-bit slackos should not used with 'ubuntus/debians' nor vice-versa.
This is the last time I'm going to mention that my own exploration suggested that 'ubuntu' and 'debian' puppys had no difficulty reading the contents of /lib64, /usr/lib64 and /usr/local/lib64 folders. That exploration was conducted under Xenialpup64 and/or tahrpup64 and --there since having been changes to woof-- may not hold true for Bionicpup64, fossapup64 or other recent Puppys.