Kernel source, Documentation folder?
- Thread starter Domino
- Start date
Maybe you figured it already out, but be sure to note the difference between the packaging repository pve-kernel.git and the current used kernel source code, located in the submodules subdirectory as git submodule.
One holds mostly meta and build stuff plus a few backported/not yet upstreamed changes, the other the kernel repo itself.
One holds mostly meta and build stuff plus a few backported/not yet upstreamed changes, the other the kernel repo itself.
@t.lamprecht - thank you for that info, is there a way for the make command to take both paths into consideration? as things are split out like this? at the moment if I use the submodules kernel source path I get "No utsrelease" failure.
I guess I can just create a merged folder with both but overriden by the backported tree? but if there is a cooler way to do it without copying files around I'm all ears.
Looking through the kernel makefile, it appears that's what it does too, so I guess I'd have to do the same thing, no problem. Just thought maybe there was a method I've not come across yet, always wanting to learn new tricks.
Looking through the kernel makefile, it appears that's what it does too, so I guess I'd have to do the same thing, no problem. Just thought maybe there was a method I've not come across yet, always wanting to learn new tricks.
Last edited:
It copies it around mostly to have a dedicated build folder, i.e., not cluttering the source directory - not for another purpose.
After that patches are currently applied with patch directly, albeit that's mostly because I'm too lazy to move it back to quilt/dpkg-buildpackage integrated approach.
It depends on what you want to do, bisect a regression or do a single time change?
In general, you should also be able to just edit/apply patches in the submodule/<kernel-src> directory and do a
make deb in the upper pve-kernel git directory, can get you a long way.Understood.
I'm trying to build a modified version of the t4_tom and nvme-offload kernel modules (latest chelsio offloading drivers), as the inbox drivers are the standard nic drivers rather than offload enabled.
Definitely some fun as I try and get Chelsio driver code patched enough to compile against 5.4.41
(kind of why I was asking the other day it would be nice to have these offloading drivers already compiled into the proxmox build to make it easier for users to just get up and running with simply a few commandline entries/scripts.
Unfortunately I understand the hard roof of working with upstream on base drivers, if Chelsio haven't released the code for the appropriate kernel then it simply won't exist unless someone is willing to invest the time to patch up their drivers for newer kernels.
I'm trying to build a modified version of the t4_tom and nvme-offload kernel modules (latest chelsio offloading drivers), as the inbox drivers are the standard nic drivers rather than offload enabled.
Definitely some fun as I try and get Chelsio driver code patched enough to compile against 5.4.41
(kind of why I was asking the other day it would be nice to have these offloading drivers already compiled into the proxmox build to make it easier for users to just get up and running with simply a few commandline entries/scripts.
Unfortunately I understand the hard roof of working with upstream on base drivers, if Chelsio haven't released the code for the appropriate kernel then it simply won't exist unless someone is willing to invest the time to patch up their drivers for newer kernels.
Rather ask the driver developers to upstream it to the mainline kernel, more people profit from that and it's ensured it got a review from developers with in-depth domain knowledge...
I'd do that directly in the submodules source tree until you got it right, or at least to compile, much easier to do modify/compile cycles. Then move it over as patch to the pve-kernel/patches directory to get a deb package.
If you need to do also frequent boot test I'd suggest setting up a copy over vmlinuz image, rebuild initrd and then kexec into the build kernel approach - much faster for that in general.
From what I have deduced through email exchanges with Chelsio support, they're not really big fans of supporting Debian as priority, they are hell bent on sticking with Red Hat, lo and behold RHV comes with all the offloading features enabled. The growth of Proxmox in enterprise is getting noticed by hardware manufacturers and hopefully in good time Debian will gain better support from manufacturer driver developers. Fingers crossed.
For now it is going to be just us part-time 'hackers' trying to get things to work.
Yes, I will take your advice on board (though I may need some assistance if I hit a wall), and do the patch that way, it does indeed make sense.
If my endeavours are successful my effort can at least be easily portable to other Proxmox users with Chelsio hardware.
Fresh off the press - Well good news is that I have actually JUST NOW got the modules built successfully!!! Now for a late evening of ample testing!
For now it is going to be just us part-time 'hackers' trying to get things to work.
Yes, I will take your advice on board (though I may need some assistance if I hit a wall), and do the patch that way, it does indeed make sense.
If my endeavours are successful my effort can at least be easily portable to other Proxmox users with Chelsio hardware.
Fresh off the press - Well good news is that I have actually JUST NOW got the modules built successfully!!! Now for a late evening of ample testing!