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

[John Criswell]

On 4/28/13 11:42 AM, Jovi Zhang wrote:
> Hi,
>
> First of all, I didn't study on compiler too much, I'm a Linux kernel developer,
> Now I have one idea about compile kernel module by using llvm framework.
>
> In Linux world, traditionally compile Linux kernel module only have one way:
> compile it to machine code directly, deploy to target machine, then
> run it in target machine.
>
> This have some problem from long term view, especially kernel module
> compatibility issue,
> we know that Linux kernel change fast, when kernel change the data
> structure exposed to external
> kernel modules, then all ko depend on that data structure will need
> recompile, one case is
> kernel upgrade.
> This is really a problem, we already suffered it many years, in whole
> Linux world.
> Linux distribution suffer it, third party kernel modules developers suffer it.
> hardware driver developers also suffer it, we cannot avoid re-compile
> kernel modules whenever new kernel
> release if the structure changed, why? because kernel modules depend
> on kernel header data structure, this is the point.

The basic idea seems feasible, but I think this is a "devil in the 
details" sort of project.  As Joshua has pointed out, there are certain 
constructs you can't use (such as sizeof() in preprocessor #if 
statements), and I think you'd need to enhance the LLVM IR to represent 
unknown structure sizes symbolically.  There is also the fact that the 
Clang frontend generates architecture-specific code and that there are 
LLVM optimizations that use the size of structures for optimization.  
That is all stuff that your project would have to "fix."  You'd be 
swimming against a strong current, so to speak.

More importantly, while you raise a number of limitations of linking 
native code for kernel modules, I don't think the Linux community sees 
this is a disadvantage.  Rather, they see it as a way of encouraging 
developers to open-source their drivers and have them included in the 
Linux kernel tree.  I'm not convinced that you'd get buy-in from the 
Linux community.

If this sort of project interests you, then I think you should aim for 
something smaller and that has more interest.  For example, I think the 
NaCL developers at Google were looking at ways to make the LLVM IR more 
suitable as a format for shipping NaCL plugins.  If that hasn't been 
done yet, it's an easier problem to tackle, and there is a group that is 
already interested in having it.

Finally, as a shameless plug, your project idea reminds me of the LLVA 
work that was done here at Illinois (which became the foundation for my 
own research on the Secure Virtual Architecture). That work aimed to 
replace the processor native instruction set with the LLVM IR to allow 
the processor to adapt without requiring manual recompilation of 
software.  You can find those papers on the llvm.org publications page 
if you're interested.

-- John T.



>
> Is there have any method to fix it? let's try to decouple kernel
> modules with kernel, by using llvm.
> Please give comments on following mechanism, 3 steps:
>
> 1) kernel modules developer compile C file into high level IR, not to
> machine code.
>
> 2) In install time, the high level IR file "link" with kernel header
> data structure file, generate  low level
> IR file, it could be .bc or .ll file in llvm form.
>
> 3) llvm compile the low level IR file into machine code in target
> machine, then insert kernel modules, run it.
>
> Using this method, kernel module code is not need to change when
> kernel header file change, because it evaluate
> structure type info at install time, not C code compile time. it fix
> compatibility  issue in a clean way.
> The key point of this method is we need defer structure type
> evaluation into install time, Is Clang support
> this "feature" at present?
>
> How about this idea sounds? I really think llvm design is nature to
> suit this idea, benefit from llvm's IR.
> If we really implement this idea, it would be very valuable for whole
> Linux community, trust me:)
>
> I would appreciate if you can give me some technical comments on this design.
> Thanks very much.
>
> .jovi
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev