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

Jovi Zhang bookjovi at gmail.com
Mon Apr 29 05:14:57 PDT 2013


On Mon, Apr 29, 2013 at 3:11 PM, Jean-Daniel Dupas
<devlists at shadowlab.org> wrote:
> Just out of curiosity, what would be the main benefit of this approach vs DKMS which is already widely used ?
>
Thanks Dupas.

I checked DKMS you mentioned, basically DKMS is just a ko and its
sources management tool.

It's not easy to deploy ko source into target machine, and it's more
harder to build ko in target machine,
this is a very common case, especially in embedded Linux, you really
cannot put source into target device,
for example, you didn't see any kernel module source in android phone, right?

What I really want to see is kernel module source don't need to to
change when kernel changes, whatever kernel
upgrade or minor structure change, DKMS cannot meet this.

what's the benefit of that?

we can replace kernel as we want, and don't need to worry ko cannot
work in new kernel, this is the true decouple,
not the decouple implementation in DKMS claimed.
Imaging that you want upgrade the android kernel to kernel mainline by
yourself, you really could do this if using the mechanism
I said, but you definitely cannot achieve this currently or use DKMS.

Another case is fast kernel debugging, just replace kernel, to check
functionality or performance in new kernel, without ko recompile,
ko may provided by different vendor, we cannot contact every vendor to
request they deliver new ko to let us try our new kernel.



More information about the llvm-dev mailing list