I am trying to understand character special files. From wikipedia, I understand that these files
"provide an interface" for devices that transmit data one character at a time. My understanding is that the system somehow calls the character device instead of calling the device driver directly. But how does the file provide this interface? Is it an executable that translates the system call? Can someone explain what's up.
Character Device Files – How Do Character Device or Character Special Files Work?
driversfiles
Related Solutions
Was the idea behind the controller to be able to control devices from a different manufacturers with the same driver?
No. The primary purpose is to provide part of the interface between devices and the processor. A controller has its own driver; this is in addition to any drivers necessary for the devices connected to it.
The reason the interface is necessary is that the processor is highly specialized; controllers are sort of translators from the specialized world of the processor to the multiverse of devices. The processor only has one physical data connection to the outside (the bus), not a variety of them, and in fact, generally intermediary between controllers and the processor are bridges which connect the processor to the motherboard. Device controllers are then connected to the motherboard and communicate via a bridge. So there are four discrete physical entities in the chain: processor -> bridge -> controller -> device, all of which involve their own software drivers (a driver for the processor, for the bridge chipset, then for each of the controllers, and for each of the devices).
If you look at the diagram below from this wikipedia article, the blue boxes at the bottom represent device controllers.
[By Alexander Taubenkorb, Creative Commons Attribution-Share Alike 3.0]
The user calls library functions that wrap around the system calls (raw syscall is quite rare for a normal programmer). The module code runs in kernel mode anyway, so at some point, there must be a context switch from user space to kernel space. Ideally, most modules will use standardized interfaces (device nodes, netlink sockets, even inet sockets), so that the interaction from the user side will be mostly through read() and write() system calls (ioctl is also quite common, as it covers the "extra" settings that don't fall under standard systemcalls). Buffers will diminish the number of calls, but at the end there's always a system call involved.
Best Answer
They are actually just that - interfaces. Encoded by a "major" and "minor" number they provide a hook to the kernel.
They come in two flavors (well, three, but named pipes are out of the scope of this explanation for now): Character Devices and Block Devices.
Block Devices tend to be storage devices, capable of buffering output and storing data for later retrieval.
Character Devices are things like audio or graphics cards, or input devices like keyboard and mouse.
In each case, when the kernel loads the correct driver (either at boot time, or via programs like udev) it scans the various buses to see if any devices handled by that driver are actually present on the system. If so, it sets up a device that 'listens' on the appropriate major/minor number.
(For instance, the Digital Signal Processor of the first audio card found by your system gets the major/minor number pair of 14/3; the second gets 14,35, etc.)
It's up to udev to create an entry in
/devnameddspas a character device marked major 14 minor 3.(In significantly older or minimum-footprint versions of Linux,
/dev/may not be dynamically loaded but just contain all possible device files statically.)Then, when a userspace program tries to access a file that's marked as a 'character special file' with the appropriate major/minor number (for instance, your audio player trying to send digital audio to
/dev/dsp), the kernel knows that this data needs to be transmitted via the driver that major/minor number is attached to; presumably said driver knows what to do with it in turn.