I have two devices that are interfaced with PCI. I also have code for both devices that uses generic socket code. (The devices were originally connected by MII/Ethernet.)
Now, I need to write a PCI device driver to transport packets back and forth between the two devices.
How do I access the file descriptors opened by the socket code? Is this the same as accessing a character device file?
The PCI driver has to somehow capture packets from read() and write() in the code.
Thanks!
The answers to your questions are: (1) You don't, and (2) no.
File descriptors are a user-space concept, and kernel drivers don't interact with user-space concepts. (Yes, they're implemented by the kernel, but other device drivers don't get to play with them directly, and shouldn't play with them even indirectly.)
What you do is implement methods that will receive data that is buffered in a kernel-accessible memory space, and send that to your hardware, and then receive data from your hardware and write it (when asked) to a buffer in kernel-accessible memory.
You'll do this by implementing the character device driver APIs as well as the PCI device driver APIs and then registering your driver as a PCI device, and then a character device. While some of these methods may refer to file structures, they will not be the user-land structures that you know and love.
For devices that implement the Ethernet protocols, life is easier because you implement the Net Device Interface instead. This way all you have to write is the parts necessary to get data to and from your hardware.
What you'll need is specifications for the device hardware, how you control the hardware using PCI registers and regions.
The good news is, you don't have to do this alone -- there's a large community of kernel developers, and several good (and current) books on developing for the Linux kernel (see below).
References
Understanding the Linux Kernel
Linux Device Drivers
Essential Linux Device Drivers
Related
I want to read the CAN bus and get the data from a specific device on the CAN bus. I have implemented this previously using the Socket communication api that is available in the user space (sys/socket).
I now have a similar requirement but this time working on device drivers which work in the kernel space. The same socket communication is i suppose not available in the kernel space which is why i guess i am not able to compile the kernel module with #include .
An approach i have come up to is to create a device driver for device creation and a supporting user-space program to interact it and provide CAN data by using socket communication. If there is any better approach please suggest me.
As far as I understand the USB devices introduce themselves by sending a device descriptor to the host which uses the information embedded in the descriptor to find and load the right driver/drivers. What I don't understand is why the drivers need the configuration, interface, endpoint and string descriptors from the device. I know the descriptors describe the device as a whole e.g. number of configurations, interfaces, endpoints, types, the size of the packets, the purpose of each byte in the packet etc. Why can't the drivers include this information from the start? Why does the USB device hold this information?
I guess the main reason is because it was designed that way. The designers could just as easily have gone the other way as you say.
Possibly more helpfully, I can think of a few reasons why they did decide on it this way:
Consider the context in which USB came about. PC peripheral connectivity was a mess. You had serial (UART) ports, PS/2 keyboard & mouse, parallel ports in various modes (e.g. ECP and EPP), game port & MIDI, the various SCSI variants, etc. Most of these did not allow for self-describing devices in a standardised way, demanding custom drivers for each type of device, and mostly manual driver loading. Device descriptors alone would mostly solve the problem of selecting the correct driver, but not necessarily the issue of needing a custom driver for each device.
Various standard device class specifications (e.g. HID, audio) define their own class-specific descriptors for communicating device variations to the standard driver. For this reason alone the generalised descriptor mechanism is useful.
Composite devices in their present form would effectively not be possible without standardised interface descriptors. You'd presumably have to make each composite device act as a hub with multiple devices attached.
Many (most?) standard device class specifications mandate a certain minimum number of endpoints where the standardised protocol is implemented, (e.g. bulk-only USB mass storage defines 1 bulk input and 1 bulk output endpoint) while devices are free to add more for vendor-specific extensions, or…
…future expansion of the standard device class or USB standard itself while maintaining backwards compatibility both ways (old driver/new device, new driver/old device). Think of UASP devices that fall back to regular bulk-only mass storage transport.
While not strictly necessary for making all those things happen, making devices self-describing in this way does seem to have been a success overall.
I am curious about how drivers in general work. I do understand basic concepts and also how a single driver operates. Where I am confused is how they work when multiple drivers are involved.
Let me explain my question through an example:
Suppose I have a PCIe and USB interface in HW. The primary interface to host (where driver, OS, applications reside) is PCIe. USB interface is accessible to host through PCIe.
So, in this case, I would have driver for PCIe as well for USB.
When data has to be transferred through USB by application, application would invoke system/OS calls. This would eventually land up in USB driver.
Is this correct?
Once USB driver has completed processing, PCIe calls have to be called. Who does it? is it OS or USB driver itself?
I would assume that, it would be OS as otherwise it would break basic modular philosophy. But driver calling OS seems counterintuitive as I always assumed flow to be from application to OS to driver and HW.
Can anyone please throw some light on this topic?
Much like in user space code, there exist standardized APIs for access various types of hardware in kernel land(exact usage varies by OS). As a result it isn't really that much of a stretch for one device driver to access another device's driver via these standardized APIs. (Warning: USB is a very complex protocol, and many details have been glossed over to keep a long post shorter)
The original question focused on PCIe to USB cards. In this example I think it's helpful to think of there being three "layers" of drivers. The first layer is the PCIe bus controller driver, which controls PCIe bus specific functions such as mapping out MMIO for PCIe devices and supporting interrupts from those PCIe devices. The second layer is the USB host controller layer, which provides the functions for issuing standardized USB transactions. Finally, the USB device driver (like a USB driver keyboard) sits on top of the stack using the standardized USB transaction to implement the functionality of the specific USB peripheral device. Calls from the keyboard driver will call functions down in the USB host controller driver, which in turn may even call down to the PCIe driver. All of this is done in the kernel space, even though many separate drivers are employed.
Most PCIe devices do the bulk of their communication with the CPU via MMIO access, which appear as memory reads/writes to the processor. Generally no specific driver function is needed to perform the MMIO transfer of data from PCIe to CPU (although there may be some simple access functions to do endian correction or deal with cache issues).
USB host controller drivers are interesting in that they conform to a standard (such as XHCI, the USB 3.0 standard, which I'll use in this example) which dictates a standard device memory map and behavior. Thus there usually is some chip specific driver performs non-standard initialization to the USB host controller device. Additionally, these chip specific drivers will both retrieve the location of the XHCI standardized MMIO region and provide a way to receive interrupts from the XHCI controller (in this example from PCIe interrupts).
Next, this standardized memory region and interrupt mechanism is passed to a generic XHCI host controller driver. The generic XHCI code does not care if the device is PCIe, it just cares that it gets passed a memory region that follows the XHCI standard and that it receives the correct interrupts The XHCI driver provides the generic USB transfer functions which in turn the USB keyboard device can use to initiate USB transactions.
For the most part, the XHCI driver is just going to do read/writes to the MMIO region that was passed in. This allows the same common XHCI code to service a wide array USB host controllers, many of which are not PCIe devices. Thus effectively allowing the XHCI driver to abstract away the underlying hardware implementing the USB controller. Thus, for the example posed by the original question, the USB host controller standards are designed to hide the underlying hardware mechanisms to make for a more modular USB driver system.
As far as I understand it, any program gets compiled to a series of assembly instructions for the architecture it is running on. What I fail to understand is how the operating system interacts with peripherals such as a video card. Isn't the driver itself a series of assembly instructions for the CPU?
The only thing I can think think of is that it uses regions of memory that is then monitored by the peripheral or it uses the BUS to communicate operations and receive results. Is there a simple explanation to this process.
Sorry if this question is too general, it's something that's been bothering me.
You're basically right in your guess. Depending on the CPU architecture, peripherals might respond to "memory-mapped I/O" (where they watch for reads and writes to specific memory addresses), or to other specific I/O instructions (such as the x86 IN and OUT instructions).
Device drivers are OS-specific software, and provide an interface between the OS and the hardware.
A specific physical device either has hardware that knows how to respond to whatever signals from the CPU it monitors, or it has its own CPU and software that is often called firmware. The firmware of a device is not specific to any operating system and is usually stored in persistent memory on the device even after it is powered off. However, some peripherals might have firmware that is loaded by the device driver when the OS boots.
There are simple explanations and there are truthfull explanations - choose one!
I'll try a simple one: Along the assembly instructions, there are some, that are specialized to talk to peripherials. The hardware interprets them not by e.g. adding values in registers oder writing something to RAM, but by moving some data from a register or a region in RAM to a peripherial (or the other way round).
Inside the OS, the e.g. the sound driver is responsible for assembling some sound data along with some command data in RAM, and the OS then invokes the bus driver to issue these special instructions to move the command and data to the soundcard. The soundcard hardware will (hopefully) understand the command and interpret the data as sound it should play.
I am currently dealing with two devices connected to the I2C bus within an embedded system running Linux. I am using an exisiting driver for the first device, a camera. For the second device, I have successfully implemented a userspace program with which I can communicate with the second device. So far, both devices seem to coexist happily. However, almost all I2C devices have their own driver module. Thus, I am wondering what the advantages of a driver module are. I had a look at the following thread...
When should I write a Linux kernel module?
... but without conclusion.
Thus, what would be the advantage of writing a I2C driver module over a userspace implementation?
Regards,
Stefan
In your situation, you probably don't have much use for a I2C driver module. If it ain't broke....
The main reason I would include a kernel module driver is when another kernel mode driver is a I2C client, or benefits from tight integration with the kernel. One example of this is the WM8350 audio codec, which is communicates audio data over an audio bus (I2S or AC97) and configuration (e.g. volume level) over I2C.
A power management IC is another example of a chip that you would want the kernel to directly control.
Finally, I will note that there are multiple kinds of I2C drivers. (See Documentation/i2c/summary.) In some cases your hardware might require an I2C bus adapter driver, to teach how to communicate over I2C. That would require a kernel mode driver.