Update Linux headers from v5.10.5 to v6.6

[cmuellner]

This patch imports the Linux kernel from v5.10.5 to v6.6. Important RISC-V-specific changes are:

• hwprobe support
• V support (ptrace and prctl calls)
• KVM support

There are patches on the glibc list that introduce code that uses the hwprobe interface. Let's update the kernel headers to be ready for these changes.

[TommyMurphyTM1234]

Just curious - and apologies if it's a dumb question - but, is there a reason that these are copied/duplicated here rather than being a Git submodule pulled from the upstream repo like most other components here?

[cmuellner]

These need to be built from Linux sources.
We could have a submodule for the Linux kernel and build/install the headers.
But cloning the Linux kernel takes quite some time.
So, having these "built artifacts" (even if they are sources/headers) is probably a reasonable compromise.

[TommyMurphyTM1234]

These need to be built from Linux sources. We could have a submodule for the Linux kernel and build/install the headers. But cloning the Linux kernel takes quite some time. So, having these "built artifacts" (even if they are sources/headers) is probably a reasonable compromise.

Ok, fair enough. I was just asking on the (slim) chance that the issue hadn't been considered before. 🙂

[kito-cheng]

hwprobe is what we need for further ifunc support, thanks!

[TommyMurphyTM1234]

These need to be built from Linux sources. We could have a submodule for the Linux kernel and build/install the headers. But cloning the Linux kernel takes quite some time. So, having these "built artifacts" (even if they are sources/headers) is probably a reasonable compromise.

Ok, fair enough. I was just asking on the (slim) chance that the issue hadn't been considered before. 🙂

What about using git sparse-checkout to fetch just the Linux headers from the upstream Linux repo instead of duplicating them here manually?

• https://git-scm.com/docs/git-sparse-checkout

[cmuellner]

It is not just copying the include directory.
These headers are "built". The top-level Makefile lists these steps:

[...]
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
[...]
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
        $(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
        $(Q)$(MAKE) $(hdr-inst)=include/uapi
        $(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
[...]

We could duplicate all required steps to build the kernel headers and just fetch the required parts, but this seems to be fragile and might break when Linux changes the build processes for these headers.

That said, I think it is doable to come up with something that fits our needs. But why waste a few days fiddling around with that when a simple make headers_install ARCH=$ARCH INSTALL_HDR_PATH=$KH does the job?

[TommyMurphyTM1234]

It is not just copying the include directory. These headers are "built". The top-level Makefile lists these steps:

[...]
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
[...]
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
        $(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
        $(Q)$(MAKE) $(hdr-inst)=include/uapi
        $(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
[...]

We could duplicate all required steps to build the kernel headers and just fetch the required parts, but this seems to be fragile and might break when Linux changes the build processes for these headers.

That said, I think it is doable to come up with something that fits our needs. But why waste a few days fiddling around with that when a simple make headers_install ARCH=$ARCH INSTALL_HDR_PATH=$KH does the job?

Thanks @cmuellner - I assumed that it was just a static copy of the headers. I didn't realise that they needed a "build/install" step.