[LLVMdev] A new mechanism to compiler kernel modules using llvm: Defer type evaluation in clang?

[Jovi Zhang]

On Tue, Apr 30, 2013 at 4:13 PM, James Courtier-Dutton
<james.dutton at gmail.com> wrote:
> Jovi,
>
> The problem with kernel module binary compatibility is that if you
> fixed the kernel module binary API, it will stifle innovation within
> the kernel.
> So, to the kernel developers, a changing module API is a bonus feature
> and not an issue. I expect you will have no support from the LKML.
> What is it in your current kernel driver that prevents it from being
> open sourced?
> What stops you from releasing a datasheet for your hardware?
>
Thanks James.

I can list hundreds of reasons on why there exist out of tree kernel modules:
code quality is not good to upstream;
kernel community think the feature is not very common, so it's not
worth to upstream;
kernel community reject the kernel modules;
company don't want to assign a long term module maintainer;
company don't want to release kernel modules source, kernel allow for
this(see EXPORT_SYMBOL);
the functionality is duplicated in mainline, but company must maintain
the interface for old customers;
company have many kernel version product, so it have to maintain
different modules sources, but mainline only maintain one version.
many famous open source kernel modules also not upstream, like
Systemtap from redhat, why this happen?
...

The truth is there, many kernel modules is out of tree, why we need to
argue this truth?

Frankly, we have a little out of topic now, I guess you don't have
engaged this kernel module
binary compatibility issue before, the world is not that simple as
upstream can solve anything.

(Look Microsoft, is all drive company upstream the driver source to
Microsoft? to solve driver compatibility issue)

Let's back to original topic: how to use LLVM mechanism to solve
kernel module binary compatibility issue in a good way?

Thanks.