I am quite new to Linux and I was going through some online tutorial
and got over two ways for altering the kernel parameter:
create /lib/modprobe.d/XYZ.conf file and put for example something like options cdrom lockdoor=0
navigate to /etc/sysctl.d, create some file like mnq.conf and put something like aaa.bbb.ccc=0
What is the difference between these two ways?
To understand the difference, let's see when these parameters are applied to the boot process:
Kernel (vmlinuz) is loaded with default sysctl parameters (nowhere to read actual parameters yet). No modules (drivers) are present at the moment (these are separate entities!).
Kernel reads initial ram disk with modules
Kernel loads modules for disk drivers and other modules needed for booting. These drivers might need some tuning (i.e. certain SCSI devices might cause initialization timeouts without proper setting). These settings also need to be applied before starting driver initialization, hence modprobe and module params in general implementation.
...
System services are starting including sysctl service which applies both kernel and some module parameters dynamically (at runtime). Those parameters doesn't affect workability of the kernel, rather than simple stability/performance tuning.
Related
I am working on a Linux device driver for a piece of hardware that relies on some configuration specific to each implementation. On the first boot-up, we require a user-space application to generate this configuration data through a calibration process. Naturally, I would store this configuration data in a file and read this file when the driver is loaded or the hardware is configured.
Reading from a file from inside kernel-space, however, is highly discouraged.
All user-space/kernel-space interaction should occur through the sysfs interface. This confuses me a little bit for two reasons:
The sysfs file-system is virtual, so every time the kernel is booted, the user (or user-space application) would have to write the configuration data to the sysfs filesystem for the kernel to use it.
The driver probe function is run long before a user-space application would have the the ability to write to sysfs.
Are my assumptions about sysfs correct? How would I be able to get this configuration data to the kernel without having to rely on a user-space application to write it to sysfs?
If use of the ramdisk is possible in your case, you could do the configuration in some script in this ramdisk, like for example:
# insmod module.ko
# cat config.file > /sys/sys_file
Such a solution will allow you to configure quite early your kernel module.
This is a hypothetical question. Suppose there is an application (which typically executes in user mode) that wants to access kernel data structures, read register values, and perform some kernel-level functions.
Is there a way for kernel and/or CPU to allow this application to perform its functions while maintaining the normal user-level/kernel-level isolation for other applications except this one?
In order to either put your app in kernel space (kernel memory) or to run it in ring 0 CPU mode, you will need to do that from kernel code. In normal state of operation you can't run app from the kernel with mentioned privileges (at least there is no existing API to do that). It's probably possible to implement some kernel code which is able of this. But it will be tricky and will mess up the whole concept of kernel-space/user-space separation, and if any advanced user-space API was used -- it won't work anyway.
If you are thinking about just giving your app ring 0 privileges -- it won't work either, because kernel has its own stack and because of kernel-space/user-space memory separation, so you won't be able to run internal kernel API.
Basically, you can achieve the same thing by writing kernel module instead. And for running some kernel code on behalf of user-space app -- you can use system calls interface.
So, answering your question: no, it's not possible to run user-space app in kernel mode so it can use internal kernel API.
From definition of monolithic kernel, it says that it exists as single bin file in an address location, and it varies from micro-kernel in a sense that in micro-kernel, there are servers which run in kernel and user-space.
My question here is that shell interprets the user commands for the kernel, so does it mean shell exists in the user-space ?
If yes isn't the interaction between kernel and shell just like it happens in micro-kernel using message passing ?
So how does micro-kernel differ from monolithic kernel ?
http://en.wikipedia.org/wiki/Monolithic_kernel see the image it give you clear picture.
It is NOT about kernel and u-space application interaction.
In micro-k let say you are reading a file then file-system server comes into the picture. user send request to file system server but to read a file from device you need driver so file system server must have to communicate with device drivers server (message passing occurs between two core functionality of OS file system and device driver)
In case of Mono-kernel everything (like file system , device drivers so on) is part of kernel and it is single-flow no message between kernels subsystems like file systems and device drivers.
You can find other major difference in the link http://en.wikipedia.org/wiki/Microkernel
From a general standpoint, I am trying to figure out how to access a platform device from userspace. To be more specific, I have a EMIF controller on and SoC of which I have added to my device tree and I believe it is correctly bound to a pre-written EMIF platform device driver. Now I am trying to figure out how I can access this EMIF device from a userspace application. I have come accross a couple different topics that seem to have some connection to this issue but I cannot quite find out how they relate.
1) As I read it seems like most I/O is done through the use of device nodes which are created by mknod(), do I need to create a device node in order to access this device?
2) I have read a couple threads that talk about writting a Kernel module (Character?, Block?) that can interface with both userspace and the platform device driver, and use it as an intermediary.
3) I have read about the possibility of using mmap() to map the memory of my platform device into my virtual memory space. Is this possible?
4) It seems that when the EMIF driver is instantiated, it calls the probe() fucntion. What functions would a userpace application call in the driver?
It's not completely clear what you're needing to do (and I should caveat that I have no experience with EMIF or with "platform devices" specifically), but here's some overview to help you get started:
Yes, the usual way of providing access to a device is via a device node. Usually this access is provided by a character device driver unless there's some more specific way of providing it. Most of the time if an application is talking "directly" to your driver, it's a character device. Most other types of devices are used in interfacing with other kernel subsystems: for example, a block device is typically used to provide access from a file system driver (say) to an underlying disk drive; a network driver provides access to the network from the in-kernel TCP/IP stack, etc.
There are several char device methods or entry points that can be supported by your driver, but the most common are "read" (i.e. if a user-space program opens your device and does a read(2) from it), "write" (analogous for write(2)) and "ioctl" (often used for configuration/administrative tasks that don't fall naturally into either a read or write). Note that mknod(2) only creates the user-space side of the device. There needs to be a corresponding device driver in the kernel (the "major device number" given in the mknod call links the user-space node with the driver).
For actually creating the device node in the file system, this can be automated (i.e. the node will automatically show up in /dev) if you call the right kernel functions while setting up your device. There's a special daemon that gets notifications from the kernel and responds by executing the mknod(2) system call.
A kernel module is merely a dynamically loadable way of creating a driver or other kernel extension. It can create a character, block or network device (et al.), but then so can a statically linked module. There are some differences in capability mostly because not all kernel functions you might want to use are "exported" to (i.e. visible to) dynamically loaded modules.
It's possible to support mapping of the device memory into user virtual memory space. This would be implemented by yet another driver entry point (mmap). See struct file_operations for all the entry points a char driver can support.
This is pretty much up to you: it depends on what the application needs to be able to do. There are many drivers in the kernel that provide no direct function to user-space, only to other kernel code. As to "probe", there are many probe functions defined in various interfaces. In most cases, these are called by the kernel (or perhaps by a 'higher level "class" driver') to allow the specific driver to discover, identify and "claim" individual devices. They (probe functions) don't usually have anything directly to do with providing access from user-space but I might well be missing something in a particular interface.
You need to create a device node in order to access the device.
The probe function is called when the driver finds a matching device.
For information on platform device API, the following articles could be useful.
The platform device API
Platform devices and device trees
Sometimes I have observed, when an application is run or calls any kernel module functions, respective kernel module is loaded automatically.
I want to build a similar kernel module which will be loaded automatically when my application executes and calls its ioctls.
Actually i want to know, what I need to write in my kernel module so that it will be loaded automatically by my application at runtime.
I looked for it a lot but didn't find anything that is satisfactory.
The keyword to search for is kmod, being the part of the Linux kernel which handles requests for loading kernel modules on the fly.
There are too many details to list in an answer here, but have a look at Linux Device Drivers, 2nd Edition' book, chapter 11 which goes into detail about kernel module autoloading.
Note that module load requests must come from within the kernel. So, if you have a device driver in a custom module but it's not loaded, the kernel has no way of knowing how to match up an ioctl request to your driver. But let's say you have a driver and some ioctl functions split into different modules A and B, it would be possible to insert the main module A to provide the device interface, and then when ioctls were requested of driver A, it could auto load the additional module B containing the ioctl functions using the kmod mechanism