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

[Jovi Zhang]

On Mon, Apr 29, 2013 at 4:40 PM, James Courtier-Dutton
<james.dutton at gmail.com> wrote:
> I am not sure this would work. It might be able to handle changes in
> structure, but what about changes in the accessor functions?

function change is not a big deal, take a example, one function
referenced in ko,
but not exist in new kernel, how could we replace new kernel in this case?
This is not a compatibility issue, because we can add some
compatibility code into new kernel
to maintain old functions for those old ko, so in this case, we still
not need to rebuild ko, right?

The case I really want to solve is some kernel change cause ko must
need to recompile,
like data structure field offset changed in new kernel, this will make
offset mismatch between new kernel
and old ko.

This is the reason why I want to delay type structure evaluation into
install time in Clang,
In theory, ko compiled now could work in 10 years later whatever how
kernel changes.


> I also don't see how this would be easier than compiling from source on the
> target machine. You still need all the kernel headers on the target machine
> because llvm with your patch would need them so that it uses the correct
> structure.
We cannot deliver source into target machine. :)
the new method don't need kernel headers in target machine, it just
need a KABI file(whatever binary or text form),
for linking with high-level IR file which compiled by ko source,
output is the low level IR file could accept by llvm,
this is the key design.

> The best approach for kernel stuff is to get the source code into mainline,
> then the source code will be kept up to date for you.
I hope that, but you know, this is not possible to put all hardware
driver and all company private ko into upstream. :)