Driver on

Linux Character Drivers | Introduction

This text, which is a part of the sequence on Linux gadget drivers, offers with the varied ideas associated to character drivers and their implementation.

Shweta, at her PC in her hostel room, was all set to discover the characters of Linux character drivers, earlier than it was taught at school. She recalled the next strains from professor Gopi’s class: “… right now’s first driver could be the template for any driver you write in Linux. Writing any specialised/superior driver is only a matter of what will get crammed into its constructor and destructor…”

With that, she took out the primary driver’s code, and pulled out numerous reference books, to begin writing a personality driver on her personal. She additionally downloaded the web e book, Linux System Drivers by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Right here is the abstract of what she learnt.

W’s of character drivers

We already know what drivers are, and why we’d like them. What’s so particular about character drivers? If we write drivers for byte-oriented operations (or, in C lingo, character-oriented operations), then we seek advice from them as character drivers. For the reason that majority of gadgets are byte-oriented, the vast majority of gadget drivers are character gadget drivers.

Take, for instance, serial drivers, audio drivers, video drivers, digital camera drivers, and fundamental I/O drivers. The truth is, all gadget drivers which can be neither storage nor community gadget drivers are some sort of a personality driver. Let’s look into the commonalities of those character drivers, and the way Shweta wrote one among them.

Figure 7

The whole connection

As proven in Determine 1, for any user-space utility to function on a byte-oriented gadget (in {hardware} area), it ought to use the corresponding character gadget driver (in kernel area). Character driver utilization is completed by way of the corresponding character gadget file(s), linked to it by way of the digital file system (VFS). What this implies is that an utility does the same old file operations on the character gadget file. These operations are translated to the corresponding capabilities within the linked character gadget driver by the VFS. These capabilities then do the ultimate low-level entry to the precise gadget to realize the specified outcomes.

Be aware that although the applying does the same old file operations, their consequence will not be the same old ones. Moderately, they might be as pushed by the corresponding capabilities within the gadget driver. For instance, a write adopted by a learn might not fetch what has simply been written to the character gadget file, not like for normal information. Do not forget that that is the same old anticipated behaviour for gadget information. Let’s take an audio gadget file for example. What we write into it’s the audio information we wish to play again, say by way of a speaker. Nevertheless, the learn would get us audio information that we’re recording, say by way of a microphone. The recorded information needn’t be the played-back information.

On this full connection from utility to the gadget, there are 4 main entities concerned:

  1. Utility
  2. Character gadget file
  3. Character gadget driver
  4. Character gadget

And the fascinating factor is that, all of those can exist independently on a system, with out the opposite being there. So, mere existence of those on a system doesn’t imply they’re linked to kind the entire connection. Moderately, they must be explicitly linked. Utility will get linked to a tool file by invoking open system name on the gadget file. System file(s) are linked to the gadget driver by particular registrations by the motive force. And the gadget driver is linked to a tool by its device-specific low-level operations. Thus, forming the entire connection. With this, word that the character gadget file will not be the precise gadget however only a placeholder for the precise gadget.

Main & minor quantity

Connection between the applying and the gadget file relies on the title of the gadget file. Nevertheless, the connection between the gadget file and the gadget driver relies on the variety of the gadget file, not the title. This enables a user-space utility to have any title for the gadget file, and permits the kernel-space to have trivial index-based linkage between the gadget file & the gadget driver. This gadget file quantity is extra generally referred because the pair, or the main & minor numbers of the gadget file. Earlier (until kernel 2.4), one main quantity was for one driver, and the minor quantity used to signify the sub-functionalities of the motive force. With kernel 2.6, this distinction is now not necessary – there may very well be a number of drivers beneath similar main quantity however clearly with totally different minor quantity ranges. Nevertheless, that is extra widespread with the non-reserved main numbers and normal main numbers are usually preserved for single drivers. For instance, Four for serial interfaces, 13 for mice, 14 for audio gadgets, …. The next command would checklist the varied character gadget information in your system:

$ ls -l /dev/ | grep “^c”

Sort: (outlined in kernel header )

dev_t // incorporates each main & minor numbers

Macros: (outlined in kernel header )

MAJOR(dev_t dev) 
MINOR(dev_t dev) 
MKDEV(int main, int minor) 

Connecting the gadget file with the gadget driver entails two steps:

  1. Registering for the vary of gadget information.
  2. Linking the gadget file operations to the gadget driver capabilities.

First step is achieved utilizing both of the next two APIs: (outlined in kernel header )

int register_chrdev_region(dev_t first, unsigned int cnt, char *title);
int alloc_chrdev_region(
    dev_t *first, unsigned int firstminor, unsigned int cnt, char *title);

First API registers the cnt variety of gadget file numbers ranging from first, with the title. Second API dynamically figures out a free main quantity and registers the cnt variety of gadget file numbers ranging from , with the title. In both case, the /proc/gadgets kernel window lists the title with the registered main quantity. With this info, Shweta added the next into the primary driver code.

#embody 
#embody 
#embody 

static dev_t first; 

Within the constructor, she added:

int ret;

if ((ret = alloc_chrdev_region(&first, 0, 3, "Shweta")) < 0)
{
    return ret;
}
printk(KERN_INFO ": <%d, %d>n", MAJOR(first), MINOR(first));

Within the destructor, she added:

unregister_chrdev_region(first, 3);

Placing all of it collectively, it turns into:

#embody 
#embody 
#embody 
#embody 
#embody 
#embody 

static dev_t first; 

static int __init ofcd_init(void) 
{
    int ret;

    printk(KERN_INFO "Namaskar: ofcd registered");
    if ((ret = alloc_chrdev_region(&first, 0, 3, "Shweta")) < 0)
    {
        return ret;
    }
    printk(KERN_INFO ": <%d, %d>n", MAJOR(first), MINOR(first));
    return 0;
}

static void __exit ofcd_exit(void) 
{
    unregister_chrdev_region(first, 3);
    printk(KERN_INFO "Alvida: ofcd unregistered");
}

module_init(ofcd_init);
module_exit(ofcd_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Kumar Pugalia ");
MODULE_DESCRIPTION("Our First Character Driver");

Then, Shweta repeated the same old steps, she learnt for the primary driver

  • Construct the motive force (.ko file) by typing make
  • Load the motive force utilizing insmod
  • Checklist the loaded modules utilizing lsmod
  • Unload the motive force utilizing rmmod

Summing up

Moreover, earlier than unloading the motive force, she peeped into the kernel window /proc/gadgets to search for the registered main quantity with the title “Shweta” utilizing cat /proc/gadgets. It was proper there. However she couldn’t discover any gadget file created beneath /dev with the identical main quantity. So, she created them by hand utilizing mknod, after which tried studying & writing these. Determine eight exhibits all these. Please word that the main quantity “250” might fluctuate from system to system based mostly on the provision. Determine eight additionally exhibits the outcomes, Shweta acquired from studying & writing one of many gadget information. That reminded her that the second step for connecting the gadget file with the gadget driver – “Linking the gadget file operations to the gadget driver capabilities” will not be but finished. She realized that she must dig additional info to finish this step and in addition to determine the rationale for the lacking gadget information beneath /dev. We will proceed additional in our subsequent article, to determine what extra is Shweta studying and the way is she going forward together with her first character driver.

Figure 8

Leave a Reply

Your email address will not be published. Required fields are marked *