linux-device-driver

LDD3 (p:453) demos dma_map_single using a buffer passed in as a parameter. bus_addr = dma_map_single(&dev->pci_dev->dev, buffer, count, dev->dma_dir); Q1 : What/where does this buffer come from? kmalloc ? Q2 : Why does DMA-API-HOWTO.txt state I can use raw kmalloc to DMA into? Form http://www.mjmwired.net/kernel/Documentation/DMA-API-HOWTO.txt L:51 If you acquired your memory via the page allocator kmalloc() then you may DMA to/from that memory using the addresses returned from those routines. L:74 you cannot take the return of a kmap() call and DMA to/from that. So I can pass the address

While trying to estimate the amount of memory consumed by a kernel module (usually device drivers),I tried using the size utility which gave the size of the static memory areas of the .ko ( .bss, .data, .text etc). So I was expecting the sum of these values to be exactly equal to the output given by the lsmod command immediately after inserting the module. No dynamic memory allocation(kmalloc or vmalloc) is performed in the init() function to ensure that it isn't causing the difference.So why is there a mismatch? Curiously the mismatch was found to be a fixed amount most of the time!! The

I'm developing a device driver module and associated user libraries to handle the ioctl() calls. The library takes the pertinent info and puts it into a struct, which gets passed into the driver module and unpacked there and then dealt with (I'm omitting a lot of steps, but that's the overall idea). Some of the data being passed through the struct via the ioctl() is uint32_t type. I've discovered that that type is defined in stdint.h AND linux/types.h. So far I've been using linux/types.h to define that value, including down in the user libraries. But I understand it is bad form to use linux/*

In a Linux uni-processor system, is timer interrupt independent of whether system is in kernel mode or user mode? Is there any different behavior for the timer interrupt while system is in kernel mode? The simple answer is that neither the execution of the hardware clock interrupt service routine, nor the scheduling of the dynamic timer handlers are affected by the mode the system was in before the hardware clock interrupt. The reason is that the the clock timer interrupt is a hardware interrupt that is serviced immediately, regardless of whether the execution is in kernel or user context

As discussed in this question, i am reserving a memory chunk at the boot time using a kernel boot parameter memmap=8G$64G I have written a character driver kernel module which , during initialization does a ioremap of this reserved memory chunk. As explained here , in my driver mmap all i need to do is remap_pfn_range for this memory chunk pointer returned by the ioremap . I am running this on 3.0 linux kernel . My user space application opens this memory chunk as a device mounted by the driver. When i do mmap from the use space application i see a system hang. my dmesg don't provide me much