I developed a kernel module and some functions on it. Now i need to develop a program in the user space and call some functions which are in the kernel module.
I also need to access some global variable that are in the kernel module on my program at the user space.
There is complete overview of linux-kernel module and user-space program interacting http://wiki.tldp.org/kernel_user_space_howto "Kernel Space, User Space Interfaces" by Ariane Keller (it is from 2008-09-28, but about 2.6 kernels; only major new way is relayfs)
No ordinary function call from user space to kernel space is listed, only syscall (adding new syscall is not easy) and upcall (call in inverse direction).
One of easiest interface is ioctl; but you can't start to use ioctl before creating procfs, sysfs or similiar file.
Other is sysctl; but sysctl is more eligible to reading/writing to global variable. (It is hard to pass several parameters via sysctl interface).
You seem to be missing the point of kernel and userland separation. If your user program could modify data inside the kernel directly, that would quickly lead to disaster.
There's only one conventional way for a user program to explicitly request services from the kernel - make a system call.
There are also traps and some Linux-specific userland-kernel communication mechanisms, but those are not relevant here.
As other posters have mentioned, there is a clear distinction between kernel and user space. So no you can't call a kernel function directly from user space. I think the easiest way to send messages between userspace and kernel space is via netlink sockets. A netlink socket allows you to easily pass arbitrary data structures between user level and kernel level.
Yes ioctl, system calls are viable alternatives, they are not as flexible as the netlink socket for passing arbitrary information.
You'll need to install a new kernel to make use of the new call unless you already have some mechanism to update the kernel ... http://www.cyberciti.biz/tips/how-to-patch-running-linux-kernel.html
Related
I know that kernel modules are used to write device drivers. You can add new system calls to the Linux kernel and use it to communicate with other devices.
I also read that ioctl is a system call used in linux to implement system calls which are not available in the kernel by default.
My question is, why wouldn't you just write a new kernel module for your device instead of using ioctl? why would ioctl b useful where kernel modules exist?
You will need to write a kernel driver in either case, but you can choose between adding a new syscall and adding a ioctl.
Let's say you want to add a feature to get the tuner settings for a video capturing device.
If you implement it as a syscall:
You can't just load a module, you need to change the kernel itself
Hundreds of drivers could each add dozens of syscalls each, kludging up the table with thousands of global functions that must be kept forever.
For the driver to have any reach, you will need to convince kernel maintainers that this burden is worthwhile.
You will need to upstream the definition into glibc, and people must upgrade before they can write programs for it
If you implement it as an ioctl:
You can build your module for an existing kernel and let users load it, without having to get kernel maintainers involved
All functions are simple per-driver constants in the applicable header file, where they can easily be added or removed
Everyone can start programming with it just by including the header
Since an ioctl is much easier, more flexible, and exactly meant for all these driver specific function calls, this is generally the preferred method.
I also read that ioctl is a system call used in linux to implement system calls which are not available in the kernel by default.
This is incorrect.
System calls are (for Linux) listed in syscalls(2) (there are hundreds of them between user space and kernel land) and ioctl(2) is one of them. Read also wikipage on ioctl and on Unix philosophy and Linux Assembler HowTo
In practice, ioctl is mostly used on device files, and used for things which are not a read(2) or a write(2) of bytes.
For example, a sound is made by writing bytes to /dev/audio, but to change the volume you'll use some ioctl. See also fcntl(2) playing a similar role.
Input/output could also happen (somehow indirectly ...) thru mmap(2) and related virtual address space system calls.
For much more, read Advanced Linux Programming and Operating Systems: Three Easy Pieces. Look into Osdev for more hints about coding your own OS.
A kernel module could implement new devices, or new ioctl, etc... See kernelnewbies for more. I tend to believe it might sometimes add a few new syscalls (but this was false in older linux kernels like 3.x ones)
Linux is mostly open source. Please download then look inside source code. See also Linux From Scratch.
IIRC, Linux kernel 1.0 did not have any kernel modules. But that was around 1995.
I was wondering why kernal_thread() isn't listed as a system call in http://man7.org/linux/man-pages/man2/syscalls.2.html?
Does a Linux application programmer never have any need to create a kernel thread?
Is the function accessible to a Linux application programmer?
Thanks.
Application programmers often need to create "kernel scheduled threads", aka "OS threads" or "native threads" using the clone syscall from that list.
"Kernel threads", however, are just threads that the kernel uses to run kernel code for its own internal purposes. They are created and used by kernel context code only. Each piece of software is responsible for creating and managing its own threads to do its own job, including userspace applications and the kernel itself.
kernel_thread is a kernel function defined in kernel/fork.c, which is not exposed to userspace. It's part of the internal kernel API and not a syscall.
As you are familiar that their are two address spaces one user and kernel, normal function will run in user space but when you will make use of some function calls that are implemented in kernel space you cannot use them directly so to access them we need system calls.
So now your question is why kernal_thread() is not listed in system calls.
(As answered by "that other guy" )
kernal_thread() function are used by the kernel programmer or usual in device driver for creating thread in kernel space. So their implementation is in kernel space and only used by kernel developer or programer. (Note:- if a interface have been provided for some function for user space that will be concluded as system call, as no interface for that function for user so their is no documentation for that in man pages)
If you want to read about documents about Kernel space function download the kernel source and check the "Documentation" folder or check the source for respective function they have few comments.
I'm developing a linux kernel module for an embedded system.
The system contains programmable logic (PL), which needs to be accessed from userspace processes.
The PL can change at runtime.
My module allows processes to access specified hw registers and pages.
These mappings are configured (at runtime) in the configfs binding of my module.
Every mapping gets an entry in configfs over which its accessible.
I would like to allow processes to mmap whole pages, so they're able to communicate directly with the PL.
But configfs doesn't support mmap.
Is there a reason why?
Sysfs supports mmap, so I see no problem why configfs shouldn't.
A solution would be to mirror my configfs tree into sysfs,
but this defeats the whole reason to use configfs... Any ideas?
configfs is not a replacement for sysfs. In fact, it can be viewed as an opposite to sysfs.
sysfs provides a view of kernel's objects though the filesystem interface. It can be used to change things in or cause some actions on those objects, but it was not meant for that. The major point here is that each object that is represented in sysfs is created and destroyed in kernel. The kernel controls the lifecycle of the sysfs representation, and sysfs is just a window on all this.
configfs, on the other hand, provides a way to create or change kernel objects through the filesystem interface. That's a fundamental difference. A user-space process can create directories within configfs. That action will cause a callback execution within the kernel and the creation of the corresponding kernel object. The files in the directory would represent states of various object's components.
I suspect that due to the nature of data exchange between the kernel and a user space process in these two cases it was deemed unnecessary to have mmap support in configfs.
Without seeing the design/architecture of your system it's difficult to say something definitive in your case. From your description is appears that sysfs may be what you need to satisfy the desired goals. All objects that you need access to are created, modified, and destroyed from the kernel. Limited settings/changes to existing kernel structures/objects in your module can be done through sysfs interface. Then again, it may well be that you would want to have both sysfs and configfs interfaces in your module, each for its specific purpose. There's nothing bad in that if it makes things cleaner and clearer.
When a process is created by do_execve, I want to write some data somewhere (say 0x0100_0000) such that after the process is run it can access that address to retrieve the data? How to achieve this task?
You can use VDSO. Example of using VDSO mechanism for own calls. The idea is to link userspace application and your code in kernel through special shared library. gettimeofday syscall is implemented in such way, what allows to reduce number of context switches.
Is there any way to add a system call dynamic, such as through a module? I have found places where I can override an existing system call with a module by just changing the sys_call_table[] array to get my overridden function instead of the native when my module is installed, but can you do this with a new system call and a module?
No, sys_call_table is of fixed size:
const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = { ...
The best you can do, as you probably already discovered, is to intercept existing system calls.
Intercepting existing system call (to have something done in the kernel) is not the right way in some cases. For eg, if your userspace drivers need to execute something in kernel, send something there, or read something from kernel?
Usually for drivers, the right way is to use ioctl() call, which is just one system call, but it can call different kernel functions or driver modules - by passing different parameters through ioctl().
The above is for user-controlled kernel code execution.
For data passing, you can use procfs, or sysfs drivers to talk to the kernel.
PS: when you intercept system call, which generally affect the entire OS, you have to worry about how to solve the problem of doing it safely: what if someone else is halfway calling the system call, and then you modify/intercept the codes?