8/14/13

Write For Us Submit Tips

Device Drivers, Part 17: Module Interactions - LINUX For You

Subscribe to Print Edition Search

HOME

REVIEWS

HOW-TOS

CODING

INTERVIEWS

FEATURES

OVERVIEW

BLOGS

SERIES

IT ADMIN

Device Drivers, Part 17: Module Interactions

By Anil Kumar Pugalia on May 3, 2012 in Coding, Developers 8 Comments

Search for:

Search

Get Connected RSS Feed Twitter

This article, which is part of the series on Linux device drivers, demonstrates various interactions with a Linux module.
As Shweta and Pugs gear up for their final semesters project on Linux drivers, theyre closing in on some final titbits of technical romancing. This mainly includes the various communications with a Linux module (dynamically loadable and unloadable driver) like accessing its variables, calling its functions, and passing parameters to it.

Global variables and functions

One might wonder what the big deal is about accessing a modules variables and functions from outside it. Just make them global, declare them extern in a header, include the header and access, right? In the general application development paradigm, its this simple but in kernel development, it isnt despite of recommendations to make everything static, by default there always have been cases where non-static globals may be needed. A simple example could be a driver spanning multiple files, with function(s) from one file needing to be called in the other. Now, to avoid any kernel name-space collisions even with such cases, every module is embodied in its own namespace. And we know that two modules with the same name cannot be loaded at the same time. Thus, by default, zero collision is achieved. However, this also implies that, by default, nothing from a module can be made really global throughout the kernel, even if we want to. And so, for exactly such scenarios, the < l i n u x / m o d u l e . h >header defines the following macros:
E X P O R T _ S Y M B O L ( s y m ) E X P O R T _ S Y M B O L _ G P L ( s y m ) E X P O R T _ S Y M B O L _ G P L _ F U T U R E ( s y m )

LINUX For You on

Follow

+2,494

Each of these exports the symbol passed as their parameter, additionally putting them in one of the default, _ g p lor _ g p l _ f u t u r esections, respectively. Hence, only one of them needs to be used for a particular symbol though the symbol could be either a variable name or a function name. Heres the complete code (o u r _ g l o b _ s y m s . c ) to demonstrate this:
1 2 # i n c l u d e< l i n u x / m o d u l e . h > # i n c l u d e< l i n u x / d e v i c e . h >

www.linuxforu.com/2012/05/linux-device-drivers-module-interactions/

1/5

8/14/13
3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1 3 2 3 3

Device Drivers, Part 17: Module Interactions - LINUX For You

s t a t i cs t r u c tc l a s s* c o o l _ c l ; s t a t i cs t r u c tc l a s s* g e t _ c o o l _ c l ( v o i d ) { r e t u r nc o o l _ c l ; } E X P O R T _ S Y M B O L ( c o o l _ c l ) ; E X P O R T _ S Y M B O L _ G P L ( g e t _ c o o l _ c l ) ; s t a t i ci n t_ _ i n i tg l o b _ s y m _ i n i t ( v o i d ) { i f( I S _ E R R ( c o o l _ c l=c l a s s _ c r e a t e ( T H I S _ M O D U L E ," c o o l " ) ) ) / *C r e a t e s/ s y s / c l a s s / c o o l /* / { r e t u r nP T R _ E R R ( c o o l _ c l ) ; } r e t u r n0 ; } s t a t i cv o i d_ _ e x i tg l o b _ s y m _ e x i t ( v o i d ) { / *R e m o v e s/ s y s / c l a s s / c o o l /* / c l a s s _ d e s t r o y ( c o o l _ c l ) ; } m o d u l e _ i n i t ( g l o b _ s y m _ i n i t ) ; m o d u l e _ e x i t ( g l o b _ s y m _ e x i t ) ; M O D U L E _ L I C E N S E ( " G P L " ) ; M O D U L E _ A U T H O R ( " A n i lK u m a rP u g a l i a< e m a i l _ a t _ s a r i k a p u g s . c o m > " ) ; M O D U L E _ D E S C R I P T I O N ( " G l o b a lS y m b o l se x p o r t i n gD r i v e r " ) ;
F acebook social plugin

Find us on Facebook

Open Source For You

Like 252,623 people like Open Source For You.

Popular

Comments

Tag cloud

May 6, 2013 6 Comments Priyanka Sarkar

PHP Development: A Smart Career Move

August 13, 2013 5 Comments Diksha P Gupta

Each exported symbol also has a corresponding structure placed into (each of) the kernel symbol table (_ _ k s y m t a b ), kernel string table (_ _ k s t r t a b ), and kernel CRC table (_ _ k c r c t a b ) sections, marking it to be globally accessible. Figure 1 shows a filtered snippet of the / p r o c / k a l l s y m skernel window, before and after loading the module o u r _ g l o b _ s y m s . k o , which has been compiled using the usual driver M a k e f i l e .

India has immense under-utilised talent in the cloud security space

June 20, 2013 3 Comments Priyanka Sarkar

What it Takes to be an Open Source Expert

June 20, 2013 2 Comments sophie-samuel

New and amazing features of Linux

May 6, 2013 1 Comments Deepti Sharma

A Simple guide to building your own Linux Kernel

Figure 1: Our global symbols module

The following code shows the supporting header file (o u r _ g l o b _ s y m s . h ), to be included by modules using the exported symbols c o o l _ c land g e t _ c o o l _ c l :
# i f n d e fO U R _ G L O B _ S Y M S _ H # d e f i n eO U R _ G L O B _ S Y M S _ H # i f d e f_ _ K E R N E L _ _ # i n c l u d e< l i n u x / d e v i c e . h > e x t e r ns t r u c tc l a s s* c o o l _ c l ; e x t e r ns t r u c tc l a s s* g e t _ c o o l _ c l ( v o i d ) ; # e n d i f # e n d i f

Figure 1 also shows the file M o d u l e . s y m v e r s , generated by compiling the module o u r _ g l o b _ s y m s . This contains the various details of all the exported symbols in its directory. Apart from including the above header file, modules using the exported symbols should possibly have this file M o d u l e . s y m v e r sin their build directory. Note that the < l i n u x / d e v i c e . h >header in the above examples is being included for the

www.linuxforu.com/2012/05/linux-device-drivers-module-interactions/

2/5

8/14/13
earlier discussion on character drivers.

Device Drivers, Part 17: Module Interactions - LINUX For You

various class-related declarations and definitions, which have already been covered in the

Module parameters
Being aware of passing command-line arguments to an application, it would be natural to ask if something similar can be done with a module and the answer is, yes, it can. Parameters can be passed to a module while loading it, for instance, when using i n s m o d . Interestingly enough, and in contrast to the command-line arguments to an application, these can be modified even later, through s y s f sinteractions. The module parameters are set up using the following macro (defined in < l i n u x / m o d u l e p a r a m . h > , included through < l i n u x / m o d u l e . h > ):
m o d u l e _ p a r a m ( n a m e ,t y p e ,p e r m )

Here, name is the parameter name, type is the type of the parameter, and perm refers to the permissions of the s y s f sfile corresponding to this parameter. The supported type values are: byte, short, ushort, int, uint, long, ulong, charp (character pointer), bool or invbool (inverted Boolean). The following module code (m o d u l e _ p a r a m . c ) demonstrates a module parameter:
1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 # i n c l u d e< l i n u x / m o d u l e . h > # i n c l u d e< l i n u x / k e r n e l . h > s t a t i ci n tc f g _ v a l u e=3 ; m o d u l e _ p a r a m ( c f g _ v a l u e ,i n t ,0 7 6 4 ) ; s t a t i ci n t_ _ i n i tm o d _ p a r _ i n i t ( v o i d ) { p r i n t k ( K E R N _ I N F O" L o a d e dw i t h% d \ n " ,c f g _ v a l u e ) ; r e t u r n0 ; } s t a t i cv o i d_ _ e x i tm o d _ p a r _ e x i t ( v o i d ) { p r i n t k ( K E R N _ I N F O" U n l o a d e dc f gv a l u e :% d \ n " ,c f g _ v a l u e ) ; } m o d u l e _ i n i t ( m o d _ p a r _ i n i t ) ; m o d u l e _ e x i t ( m o d _ p a r _ e x i t ) ; M O D U L E _ L I C E N S E ( " G P L " ) ; M O D U L E _ A U T H O R ( " A n i lK u m a rP u g a l i a< e m a i l @ s a r i k a p u g s . c o m > " ) ; M O D U L E _ D E S C R I P T I O N ( " M o d u l eP a r a m e t e rd e m o n s t r a t i o nD r i v e r " ) ;

Figure 2: Experiments w ith the module parameter

www.linuxforu.com/2012/05/linux-device-drivers-module-interactions/

3/5

8/14/13

Device Drivers, Part 17: Module Interactions - LINUX For You

Figure 3: Experiments w ith the module parameter (as root)

Note that before the parameter setup, a variable of the same name and compatible type needs to be defined. Subsequently, the following steps and experiments are shown in Figures 2 and 3: Building the driver (m o d u l e _ p a r a m . k ofile) using the usual driver M a k e f i l e Loading the driver using i n s m o d(with and without parameters) Various experiments through the corresponding / s y sentries And finally, unloading the driver using r m m o d . Note the following: Initial value (3) of c f g _ v a l u ebecomes its default value when i n s m o dis done without any parameters. Permission 0764 gives r w xto the user, r w -to the group, and r -for the others on the file
c f g _ v a l u eunder the parameters of m o d u l e _ p a r a munder / s y s / m o d u l e / .

Check for yourself: The output of d m e s g /t a i lon every i n s m o dand r m m o d , for the p r i n t koutputs. Try writing into the / s y s / m o d u l e / m o d u l e _ p a r a m / p a r a m e t e r s / c f g _ v a l u efile as a normal (non-root) user.

Summing up
With this, the duo have a fairly good understanding of Linux drivers, and are all set to start working on their final semester project. Any guesses what their project is about? Hint: They have picked up one of the most daunting Linux driver topics. Let us see how they fare with it next month.

Related Posts:
Device Drivers, Part 2: Writing Your First Linux Driver in the Classroom Device Drivers, Part 16: Kernel Window Peeping through /proc Device Drivers, Part 5: Character Device Files Creation & Operations Device Drivers, Part 13: Data Transfer to and from USB Devices Device Drivers, Part 4: Linux Character Drivers
Tags: device drivers, global variables, globals, kernel development, kernel modules, linux device drivers, Linux Device Drivers Series, linux drivers, Loadable kernel modules, Macros, namespace

Article written by:

www.linuxforu.com/2012/05/linux-device-drivers-module-interactions/

4/5

8/14/13

Device Drivers, Part 17: Module Interactions - LINUX For You

Anil Kumar Pugalia

The author is a freelance trainer in Linux internals, Linux device drivers, embedded Linux and related topics. Prior to this, he had worked at Intel and Nvidia. He has been exploring Linux since 1994. A gold medallist from the Indian Institute of Science, Linux and knowledge-sharing are two of his many passions. Connect with him: Website - Twitter - Facebook - Google+

Previous Post

Next Post

Developing Apps on Qt, Part 4

Functional Programming and Python

Reviews

How-Tos

Coding

Interviews

Features

Overview

Blogs

Search
Popular tags
Linux , ubuntu, Java, MySQL, Google, python, Fedora, Android, PHP, C, html, w eb applications , India, Microsoft, unix , Window s , Red Hat, Oracle, Security , Apache, xml, LFY April 2012, FOSS, GNOME, http, JavaScript, LFY June 2011, open source, RAM, operating systems

For You & Me Developers Sysadmins Open Gurus CXOs Columns

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherw ise noted. LINUX For You is pow ered by WordPress, w hich gladly sits on top of a CentOS-based LEMP stack.

www.linuxforu.com/2012/05/linux-device-drivers-module-interactions/

5/5