search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.63k stars 13.79k forks source link

Avoid kernel sources reference in a kernel module closure #34006

Open nlewo opened 6 years ago

nlewo commented 6 years ago

I build a kernel module by using pkgs.linuxPackages.kernel.dev to provide kernel sources. The output path of the built module have a reference to the output path of pkgs.linuxPackages.kernel.dev because there is occurrences of the pkgs.linuxPackages.kernel.dev hash in the module binary.

This is because the build Makefile in the kernel source (/nix/store/8isavlq67qrhd9xqb672h4p4waymyj24-linux-4.9.49-dev/lib/modules/4.9.49/build/Makefile) contains an occurence to the hash:

MAKEARGS := -C /nix/store/8isavlq67qrhd9xqb672h4p4waymyj24-linux-4.9.49-dev/lib/modules/4.9.49/source

As a workaround, I'm copying kernel sources and patching this Makefile to change this path before building the module. The module works well and there is no more dependencies.

I don't know what is the good way to avoid this useless dependencies. Is it possible to explicitly remove references of a derivation? Or is there a parameter at module build time to avoid this?

dezgeg commented 6 years ago

Well you need to debug why your module binary contains a string that refers to pkgs.linuxPackages.kernel.dev.

nlewo commented 6 years ago

The string is the path to a header in the kernel sources. In a .o file that is used to link the module, there is the string:

/nix/store/8isavlq67qrhd9xqb672h4p4waymyj24-linux-4.9.49-dev/lib/modules/4.9.49/source/include/linux/uaccess.h

To be honnest, it's really not easy to debug such kind of stuffs...

dezgeg commented 6 years ago

Does it install .o files? That shouldn't be needed.

But if it ends up in the .ko as well, then objdump, nm are your friends. Or looking for at the source file corresponding to the .o file or the uaccess.h file instead. Probably there's a __FILE__ reference somewhere.

nlewo commented 6 years ago

@dezgeg This .o is used to create .ko, so I suppose the string present in .ko comes from this .o. But I don't know why gcc put a link to a header in a .o.

Another point: I'm also building this kernel module with Nix by using Ubuntu kernel headers. In this case, the .ko contains a relative path to this header include/linux/uaccess.h, while when I build it with Nix kernel header, the path is absolute.

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse.
  3. Ask on the #nixos channel on irc.freenode.net.