I am working on NVMe driver in linux kernel 4.13.10 (blk-mq architecture). I'm issuing a command e.g. Read/write from an application to the nvme device. The complete sequence is as follows :
From the application, the command comes to the nvme
In driver, I'm using blk_execute_rq to submit the command to the block layer
It is observed that when the command reaches the driver again from the block layer, it is mapped to a nvme queue.. Is there any way by which I can choose the nvme queue id myself and submit the command to that particular queue only?
I think the blk_execute_rq is a generic block layer function. You need to check if any possibility to pass private data such as in the device->priv_data. If you know what function in the nvme driver gets called, then you can do a backtrace to find out where you can insert the queue_id parameter.
Related
I understand the basics behind a UIO driver, as described in the documentation. The part I'm missing is how to write data from the user space program back to the device driver. My guess is that you'd write this data to the mmap region, but then how to do you let the device driver know it should read said memory?
Ultimately I'm trying to write a block device that can be implemented by a user space program. I've got the block device code stubbed out and working: https://github.com/wspeirs/usbd. My thought was that UIO was the most efficient way to transfer blocks/sectors between the block device and the user space program. Is this the wrong way to go about communicating with the block device driver from user space? Should I be using sysfs or some other communication mechanism?
UIO is designed so that user space bypasses the kernel to communicate with a hardware device. That does not seem to fit your needs.
In a standard Linux block device, you can use mmap() to write data to your block and msync() to indicate to the driver which regions you have written.
Hi I am new to kernel driver developement. I am using the raspberry pi as my hostI am trying to create an I2C driver for a custom board we have. The custom board will act as the slave. I am confused about how do I go about entering the devices slave address. From what I understand
You need to either have a board setup file which I dont since its a custom board.
You can edit the device tree
Or you can do it in the user space application.
I am not sure where exactly to edit the device tree if I go with the second option. More over I would like to somehow register the slave address in the I2C driver itself. That way I donot need to rebuild the kernel. One method i was looking at was to set the i2c client from the driver code but that was advised by commentators I am not sure why. Any help would be appreciated.
Instantiating Drivers
So I have finally a working way in which I can bind the I2C device without needing a kernel rebuild. I create two driver files(.ko files). One for registering and one for the actual driver.
The way I did it is I got the bus number to which the device was connected.
(You can look into i2c user space code. i2cdetect -y (busnumber) will help you detect which bus number it is)
Once I knew that I created a driver file which would register my device by getting access to the adapter and then registering it. My bus number was 1 and slave address 0x10
static struct i2c_board_info board_info[] __initdata =
{
{
I2C_BOARD_INFO("my_device", 0x10),
},
};
And in the init function of the driver I register the device by
i2c_new_device(i2c_get_adapter(1), board_info[0])
Thats it. Now once you build this insmod the ko file before insmoding the actual driver file and everything should work.
It's simple and straightforward in user mode because of those APIs.
How do you read/write specified process's userspace memory from a windows kernel module?
driver target platform is windows xp/2003
Use NtWriteVirtualMemory / NtReadVirtualMemory to write to other processes - you will need to open a handle to the process first.
Note that if you're already in the process, you can just write directly - for example if you're responding to a DeviceIoControl request from a process you can write directly to user-mode addresses and they will be in the address space of the process that called you.
I'm also starting in the world of windows drivers and from what I've read XxxProcessMemory calls NtXxxVirtualMemory in ntdll (R3-UserMode).
The NtXxxVirtualMemory calls the ZwXxxVirtualMemory (R0-KernelMode) also in the ntdll.
I believe you should use the ZwXxxVirtualMemory.
In the krnel, ZwXxx routines are just wrappers around NtXxx ones, telling the kernel that the caller is a kernel mode component, rather than an user application. When a call comes from usermode, the kernel performs additional security checks.
So, use ZwXxx when in the kernel.
An alternative approach for reading/writing memory from/to another process is:
obtain address of its process object (PsLookupProcessByProcessId),
switch the current thread to its address space (KeStackAttachProcess),
perform the operation (read/write...),
switch the address space back (KeUnstackDetachProcess),
decrement reference count incremented by (1) (ObDereferenceObject).
I am new to Linux and I need to write a USB driver for a device with 2 interfaces. One interface is HID class (3/0/0) with one interrupt in endpoint and a report descriptor. The other interface is vendor defined with 3 bulk endpoints. In my usb_device_id table I have a USB_DEVICE entry with the VID and PID.
When I plug in the device, my xxx_probe function is called for the vendor defined interface but not for the HID interface. Instead, it appears that a built-in driver called 'generic-usb' is taking control of the HID interface.
Is there a way to ensure that my driver probe function is called first?
Why doesn't Linux make multiple passes looking for a more specific driver first (like Windows does)?
Alternatively, can the 'generic-usb' driver be used to receive data on the interrupt endpoint and to set reports and features on the control pipe?
It appears that libusb-1.0.8 allows an application to take control of interfaces on an attached device without the need of a custom driver. So far it appears to provide all the support that I need.
I need to retrieve the "Physical Device Object name" of a disk device from a user mode application on Windows, as seen in Device Manager.
I have a solution now that involves a kernel driver that gets loaded and interrogated through IOCTLs. Once in kernel land, I have no trouble getting to that name. If possible, I would like to avoid using a kernel module.
Any ideas?
You can get this using the Setup API functions. Specifically I believe you can get this via SetupDiGetDeviceRegistryProperty and SPDRP_PHYSICAL_DEVICE_OBJECT_NAME.