linux-device-driver

What are the ways to communicate with a kernel module from user space? By communication i mean sending information and commands between the kernel module and a user space process. I currently know of two way: open/close/read/write/ioctl on published device node. read/write on exported and hooked /proc file. More specifically, can someone advice the best way to communicate with a kernel module that does not actually drives any hardware and therefore should not be littering /dev with stub nodes that exists solely for ioctl calls? I mostly need to check its various status variables and send it a

I'm designing a device driver that simply reads and writes to a character buffer. My question is however regarding the two functions in the file_operations structure read and write . I don't truly understand what loff_t *offp really is. I know that for both the read and write operations that *offp is the file offset meaning the current reading/writing position of the file, however I'm not even sure what it means to write or read to/from a device file. From what I gathered, and this is how I am writing and reading from my device is that I create a structure which represents my device which I

From user-space we can use cpuset to actually isolate a specific core in our system and execute just one specific process to that core. I'm trying to do the same thing with a kernel module. So I want the module to get executed in an isolated core. In other words: How do I use cpuset 's from inside a kernel module? * Using linux/cpuset.h in my kernel module doesn't work. So, I have a module like this: #include <linux/module.h> #include <linux/cpuset.h> ... #ifdef CONFIG_CPUSETS printk(KERN_INFO, "cpusets is enabled!"); #endif cpuset_init(); // this function is declared in cpuset.h ... When

I'm learning about the blocking I/O functions for writing linux device driver and I'm wondering what is the usage of ERESTARTSYS . Consider the following: Global variable : wait_queue_head_t my_wait_q_head; int read_avail = 0; device_init() : init_waitqueue_head(&my_wait_q_head); device_read(): printk("I'm inside driver read!\n"); wait_event_interruptible(&my_wait_q_head, read_avail != 0); printk("I'm awaken!\n"); device_write(): read_avail = 1; wake_up_interruptible(&my_wait_q_head); When I call the read() from user space, the command prompt hang until I call the write() as expected. The

I have seen that __iomem is used to store the return type of ioremap() , but I have used u32 in ARM architecture for it and it works well. So what difference does __iomem make here? And in which circumstances should I use it exactly? Lots of type casts are going to just "work well". However, this is not very strict. Nothing stops you from casting a u32 to a u32 * and dereference it, but this is not following the kernel API and is prone to errors. __iomem is a cookie used by Sparse , a tool used to find possible coding faults in the kernel. If you don't compile your kernel code with Sparse

Why is it that every function in most device drivers are static? As static functions are not visible outside of the file scope. Then, how do these driver function get called by user space applications? Remember than in C everything is addresses. That means you can call a function if you have the address. The kernel has a macro named EXPORT_SYMBOL that does just that. It exports the address of a function so that driver functions can be called without having to place header declarations since those functions are sometimes not know at compile time. In cases like this the static qualifier is just

I've written a linux driver that ioremaps exports PCI BAR0 for a particular device to a sysfs binary attribute allowing userspace to directly control it. The problem rears when I attempt to MMAP on top of the attribute to directly access that bit of memory (from a userland program). Reads succeed just fine and return expected values, though when I write to that memory it appears to be cached somewhere between the kernel and memory and not delivered to the GMCH root complex (and therefore the device). What I'd like to do is have an implicit write memory barrier after each access. Is there any

I need to write an SPI Linux character device driver for omap4 from scratch. I know some basics of writing device drivers. But, I don't know how to start writing platform specific device driver from scratch. I've written some basic char drivers, and I thought writing SPI device driver would be similar to it. Char drivers have a structure file_operations which contains the functions implemented in the driver. struct file_operations Fops = { .read = device_read, .write = device_write, .ioctl = device_ioctl, .open = device_open, .release = device_release, /* a.k.a. close */ }; Now, I am going