Let me ask one more question.
I guess this patch is motivated by how difficult to convey kernel headers from vendors to users.
In that situation, how will the user find the right compiler to use for building external modules?
Greg KH said:
We don't ever support the system of loading a module built with anything other than the _exact_ same compiler than the kernel was.
For the full context, see this: https://lore.kernel.org/patchwork/patch/836247/#1031547
IMO this issue is not related to this patch but is just an issue with building external modules in general.
I do not think it is an issue of the build system, at least.
As far as I understood Greg's comment, it is troublesome without the assumption that vmlinux and modules are built by the same compiler. It is related to this patch since this patch assumes use-cases where external modules are built in a completely different environment, where a different compiler is probably installed.
Yes, but what I'm trying to say is the same issue exists with all other solutions today that do this. Such as debian you have linux-headers package.
Distributions provide the compiler in the standard path (/usr/bin/gcc), and users are supposed to use it for building external modules. That's the difference.
A user could totally use the build artifacts obtained from somewhere to build a kernel module with a completely different compiler. That issue has just to do with the reality, and isn't an issue caused by any one solution such as this one. I agree care must be taken whenever user is building external kernel modules independent of kernel sources. Did I miss something else?
thanks a lot,
- Joel
-- Best Regards Masahiro Yamada