Export kernel module headers to userspace - linux

I am writing a Linux kernel module which need to export some header files to userspace.
I am wondering if there is any standard method which use Kernel package to do required sanitation of headers (For example something like "$(MAKE) -C $(KERNELDIR) M=$(PWD) headers_install" if exist).
Should i take care of headers manually?
Any suggestion?

There is no such functionality out of the box because most kernel modules which need something like that come with an extra "devel" package which contains the (cleaned) header files and probably a shared library to talk to the module.
As for cleaning your headers, I suggest to split the header files into a generic part (which you export) and an internal part (which only the kernel module can see). typedef is your friend.

You can do it by adding 'header-y=' to one of the Kbuild under /include/uapi

Related

How to create shared header file for kernel filesystem and user program?

At what path should I include a header file that is needed to be accessed by both a linux kernel custom filesystem and a user program?
Existed filesystem drivers place their headers, which are also intended for user space, under include/uapi/linux/. Here you may find jffs2.h, btrfs.h and many other filesystems-related headers.
These headers are intended to be included with
#include <linux/xxx.h>
This automatically works for the kernel.
For user this would work too, after you install "uapi" headers with make headers_install, rebuild C library (libc) against new headers, and rebuild gcc against new C library. Otherwise, you need to copy required headers and adjust include directories manually.

How to make a kernel interface to user-level?

I'm building a syscall to kernel Linux, so I need to export a structure to use in user level. I've read some documentation and they said I need to use a *.h below kernel/include/uapi or use make headers_install. But nothing seems to work. gcc doesn't identify the data type I tried to export.
So, what are the prerequisites to use this command and what exactly it makes (what headers it export and under what conditions) ?

How are intermodule dependencies resolved when...?

How are intermodule dependencies resolved when both modules are built outside of the kernel tree and modversioning is enabled?
Modversioning is used to ensure that binary loadable modules are compatible with the kernels they are loaded upon. It is enabled with .config option CONFIG_MODVERSIONS.
We have two dynamically loaded kernel modules, one of which uses an exported symbol from the other. Although the module with the dependence on the other is loaded after the other, insmod complains that it can not resolve a dependency.
[FWIW, these particular modules would serve no useful purpose in the open source world. The people who designed these modules like to keep them out of the kernel tree for their own SCM purposes. The solution of deploying these as a kernel patch will not work.]
This is what the kernel log shows.
<4>foomod: no symbol version for bar_api
<4>foomod: Unknown symbol bar_api
However, if I cat /proc/kallsyms, the bar_api is there and shown as exported.
Another developer here suggested that we use a .conf file to get invoked from the loadmodules script that ignores this error and forces a load, something like this.
install foomod { /sbin/modprobe --ignore-install --force-modversion foomod
$CMDLINE_OPTS; }
I think there has got to be a cleaner way to fix this.
I've tried modifying the Makefile to reference symvers of the module exporting the symbol. The module source for each are in peer directories. It does not seem to matter, but I could be doing this wrong.
KBUILD_EXTRA_SYMBOLS := ../barmod/Module.symvers
This is the content of Module.symvers:
0x00000000 bar_api bar_api barmod
The 0x00000000 is supposed to be valid with modversioning disabled. I think if I could use modprobe like this and see the exported function, then the modprobe would be successful. However, this would only work when modversions is disabled.
# modprobe --dump-modversions foomod.ko
0x00000000 bar_api
However, copying both drivers into the kernel tree and building from within it works. This is a partial listing of the symbols referenced with checksums.
# modprobe --dump-modversions foomod.ko
0x46085e4f add_timer
0x7d11c268 jiffies
0x6a9f26c9 init_timer_key
0x7ec9bfbc strncpy
0xe43dc92b misc_register
0x3302b500 copy_from_user
0x85f8a266 copy_to_user
0xc6538cfc bar_api
0xea147363 printk
: :
Way back around ~2002 having CONFIG_MODVERSIONS would have caused the build to append a checksum generated from genksyms to each exported kernel function. Symbols would look something like this: printk_R1b7d40. This is the last time I've had to deal with modversioning since all of my work since has been with open-source code, within the stock kernel code, or with modversioning disabled. However, today's builds use genksyms to create a checksum for each symbol that goes into a special section. This special section is checked for a checksum match.
There used to be a kernel macro called EXPORT_SYMBOL_NOVERS() that would have worked, but that has been deprecated.
The Linux kernel used is 2.6.32.
I've found these articles relevant and helpful, but inconclusive:
http://lxr.free-electrons.com/source/Documentation/kbuild/modules.txt
http://lwn.net/Articles/21393/
http://www.linuxchix.org/content/courses/kernel_hacking/lesson8
http://lwn.net/Kernel/LDD2/ch11.lwn
How do I cleanly export a function from a loadable module and allow it to be used by another, dependent loadable module when both are built outside of the Linux kernel?

Is it feasible to bundle dynamic libraries with dependencies in a Tcl Starkit/Starpack?

I've written a Tcl script that uses the TclMagick extension together with GraphicsMagick.
For GraphicsMagick, I've both the Windows DLLs and the Linux SO files. I want to be able to make two Starkit/Starpack applications bundled with those libraries: one for Windows (with the DLLs) and one for Linux (with the SO files).
Is this reasonable? Can it be done?
EDIT
I cannot seem to use DLLs with dependencies under Windows. In my case, I want to use the TclMagick extension, but it needs the GraphicsMagick's DLLs and the starkit cannot find those. What should I do in this situation?
Yes. In the lib/tclmagick subdirectory of $starkit::topdir, you'll place the dynamic library and an appropriate pkgIndex.tcl file that loads the library. Use a Makefile or some other build script to use the correct dynamic library file, and generate the pkgIndex, depending the target platform.
The directory hierarchy:
appname.vfs/
main.tcl
lib/
app-appname/
appname.tcl
pkgIndex.tcl
tclmagick/
pkgIndex.tcl
tclMagick.so
package require tclmagick will work as you expect, for some capitalization of "tclmagick"
You can do it, but you might need some extra windows trickery to get things to work properly.
Windows has quite a few options to load dependent libraries, this page explains the basics:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
There are is one part that can help you:
If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
So, to get the dependencies right, you could get the dependent libraries loaded into memory first (sadly you cannot use load for this, but could use something from twapi, e.g. twapi::load_libary (see http://wiki.tcl.tk/9886) to get the library loaded from some temporary location).
Sadly most OS's do not provide an easy or portable way to load a dynamic library directly from memory, so you need to copy the dependent libs to a temporary location first (you can do it with appropriate hacks or by using something like an installable filesystem on windows/FUSE on Linux).
In most cases the easiest route is to just link all dependencies statically into the extension instead.

jiffies.h unknown

I'm using a Linux 2.6.36 on a embedded system. I try to program something with semaphores. For this I need a function from the jiffies.h library. So good so far. When I include the Lib
either this way
#include <jiffies.h>
or this way
#include <linux/jiffies.h>
works.
But the strange thing is if I go to open declaration (eclipse comand) it opens an new editor window with the library. Does anyone have a clue what to do?
You are probably not building your module correctly. A kernel module Makefile is extremely simple, and should look something like this, in its entirety:
obj-m := mymodule.o
mymodule.ko: mymodule.c mymodule.h
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
The kernel build system will do the rest. For more details, see the chapter on building modules at http://lwn.net/Kernel/LDD3/
Editing:
Now it appears maybe you aren't trying to write a kernel module after all. In that case, you don't want any include files that are part of the kernel source. jiffies.h is not a userland include; it is a part of the kernel, used in writing parts of the kernel. For userland semaphores, try POSIX semaphores. Start with man sem_overview, and/or Google "POSIX semaphore".
One mystery is solved: Eclipse store all file names in a project in a kind of list and when I click on show declaration it search in the list for that name and display the file. So it doesn't say anything about the compiler and the linker if this work. If that is not true please correct me.

Resources