> > > > 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
