Proper Linux Kernel Coding Style

Some simple rules, written and unwritten, to ensure that other kernel users understand your work.
Unwritten Rules

If you follow the above set of rules, your code will look like good Linux kernel code. However, quite a few unwritten rules and style guidelines exist that good kernel code follows. Here are some of them.

Avoid NIH Syndrome

A wide variety of well-designed, well-documented and well-debugged function and data structures can be found within the kernel. Please take advantage of them, and do not reinvent your own version of them just because you did not write them. Among the most common of these are the string functions, the byte order functions and the linked list data structure and functions.

String Functions

In the file include/linux/string.h, a number of common string handling functions are defined. These include strpbrk, strtok, strsep, strspn, strcpy, strncpy, strcat, strncat, strcmp, strncmp, strnicmp, strchr, strrchr, strstr, strlen, strnlen, memset, memcpy, memove, memscan, memcmp and memchr. And a number of “simple” string functions are defined in the file, include/linux/kernel.h: simple_strtoul, simple_strtol, simple_strtoull and simple_strtoll. So, if you need any type of string functionality in your kernel code, please use the built-in functions. Do not try to rewrite the existing functions accidentally.

Byte Order Handling

Do not rewrite code to switch data between different endian representations. The file include/asm/byteorder.h (asm will point to the proper subdirectory, depending on your processor architecture) will bring in a wide range of functions that allow you to do automatic conversions, regardless of the endian format of your processor or your data.

Linked Lists

If you need to create a linked list of any kind of data structure, use the code that is in include/linux/list.h. It contains a structure, struct list_head, that should be included within the structure of which you want to create a list. Then you will be able to add, remove or iterate over a list of data structures easily, without having to write new code.

Some good examples of code that uses the list structure can be found in drivers/hotplug/pci_hotplug_core.c and drivers/ieee1394/nodemgr.c. Some code in the kernel that should be using the list structure can be found in the ATM core, within the struct atm_vcc data structure. Because the ATM code did not use struct list_head, every ATM driver needs to walk the lists of data structures by hand, duplicating a lot of code.

typedef Is Evil

typedef should not be used in naming any of your structures. Most main kernel structures have no typedef. Though this would shorten their usage, it obscures code. For example, the core kernel structures struct inode, struct dentry, struct file, struct buffer_head, struct user and struct task_struct have no typedef.

Using a typedef only hides the real type of a variable. There are records of some kernel code using typedefs nested up to four layers deep, preventing the programmer from easily telling what type of variable they are actually using. If the programmer does not realize the size of the structure it can cause very large structures to be accidentally declared on the stack or to be returned from functions.

typedef also can be used as a crutch to keep from typing long structure definitions. If this is the case, the structure names should be made shorter, according to the above-listed naming rules.

Never define a typedef to signify a pointer to a structure, as in the following example:

typedef struct foo {
        int bar;
        int baz;
} foo_t, *pfoo_t;

This hides the true type of the variable and uses the name of the variable type to define what it is (see the previous comment about Hungarian notation).

Some examples of where typedefs are used badly are in the include/raid/md*.h files, where every structure has a typedef assigned to it, and in the drivers/acpi/include/*.h files, where a lot of the structures do not even have a name assigned to them, only a typedef.

The only place that using typedef is acceptable is in declaring function prototypes. These can be difficult to type out every time, so declaring a typedef for these is nice to do, for example, the bh_end_io_t typedef that is used as a parameter in the init_buffer() call. This is defined in include/fs.h as:

typedef void (bh_end_io_t)
    (struct buffer_head *bh, int uptodate);


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

any body know send me

Anonymous's picture

i want a unix programming code for read 10 inputs from file and stored it in other file.

I need one information: What

latha's picture

I need one information:
What are the "coding standards" used for developing a linux device driver.
If there are standards where can i get all the standards details?
If those are available in any website .Please let me know.

ifdef badness

Anonymous's picture

I don't see ifdef badness as being a binary black/white thing. Just like gotos or almost any other programming construct there are ways to use ifdef that are good or bad.

One or two here and there, used for the purpose of clarity, is potentially a good thing.

If you find you're writing a lot of ifdefs, then it is likely that there is something else you should be doing instead: macros, function calls to a CPU specific layer, or something else.

Same deal with gotos. Use goto here and there to make clearer exit paths is a Good Thing, using them to create complex branching paths is a bad thing.

And btw: there is a good way to make a macro for NULL code - something that is used all over the kernel:

#define blaah(x) if(x) printf("blaah %d\n",x)
#define blaah(x) do { } while(0)

That creates a nice macro that always gets the semicolon logic right.

Is an 'ifdef' in C code really that bad?

David Schwartz's picture

I personally think the 'ifdef' in the C code is vastly superior. For one thing, it makes it obvious to anyone looking at the code that the function is only called if CONFIG_USB_HIDDEV is defined. For another thing, the proposed 'improvement' requires someone to look at the header file to understand the C code, rather than having the C code be self-documenting.

The claimed benefit that the code is more readable is the opposite of the truth. The original code makes it clear that nothing is done if CONFIG_USB_HIDDEV is not defined. The 'improved' code obscures that.

As for it being easier to maintain, I presume this is because the selection of the appropriate hid function is now part of the hid code rather than scattered in all the code that might call the hid code. I do agree that there is some value to this, but weighed against the fact that it obscured under what cases the function does something and under what cases it does not, I think it's just not worth it.

Especially if you try to generalize this. For example, what if 'HID_CLAIMED_HIDDEV' is not defined unless CONFIG_USB_HIDDEV is defined. Would you suggest a 'hid_is_claimed' macro that always returns 'true' or 'false' if 'CONFIG_USB_HIDDEV' is not declared? But then which should it return if it's not even supposed to exist as a test?

And what if instead of 'hid->claimed' it was something like 'is_claimed(hid)'? There might be costs associated with the empty function, and when you put that empty function in the header file, you do not necessarily know about every case that might call it.

This can lead to the ultimate ugliness -- code that has no side-effects around it will call the null function. But code that has side-effects or doesn't want the cost associated with deciding whether or not to call the null function might still need an 'ifdef'. What an unsightly mess that would be.

lots of thinking

Andrew Thompson's picture

I see you've done a lot of thinking on this problem, and come up with some logical ideas, but I suspect you've never worked on code with lot's of #ifdefs, especially that needs to be portable to a number of different systems. If there are one or two, it is fine, the problem is when you get a bunch of them they are really hard to read. They don't follow normal indentation rules, so it is hard to see where they end, or what '#else' goes with which '#if'. Scary stuff.

#ifdef section question

Anonymous's picture

Just the scenario described above for moving the #ifdef out of the c and into the h comments about making a null function.

My question is...Does this when executed still make a function call during execution? Wouldn't this cause a few extra clock ticks that could be done elsewhere? Or does the compiler optimize this out of the equation?

Is the hope to avoid excessive #defines as well?

I suppose defining something else like a


#define HIDDEV_FUNCT extern void hiddev_hid_event (struct hid_device *, unsigned int usage,int value);


#define HIDDEV_FUNCT ;


and then use HIDDEV_FUNCT in the if previously would be avoided to avoid hiding the actual function.. Is this correct?

Re: #ifdef section question

gregkh's picture

Yes, the compiler optimizes any "null" inline function calls out of the object code, and will not cause any extra clock ticks.

Also, that #define will not work :)

Hope this helps

Re: #ifdef section question

Olle Bergkvist's picture

What about this one?

   extern void hiddev_hid_event (struct hid_device *,
                                 unsigned int usage,
                                 int value);
#define hiddev_hid_event(hid_device,usage,value) ;
/* the last semicolon is there to not break the logic if the call is the only statement in a block:
      hiddev_hid_event (thisdev, somethg, 0);
would become:

Besides, what would you do if you need a return value from such a function?
The method described in the guidelines only works for 'void func(args)' (if i understand correctly).

What would such an empty inline function return?

And what if you have to choose between several different function calls upon a DEFINE.

   if (hid->claimed & HID_CLAIMED_HIDDEV)
         hiddev_hid_event(hid, usage->hid, value);
         hiddev_hid_other_event_stuff(hid, usage->hid, value);

This would look like:

   if (hid->claimed & HID_CLAIMED_HIDDEV) {
         hiddev_hid_event(hid, usage->hid, value);
         hiddev_hid_other_event_stuff(hid, usage->hid, value);

which is just weird since the code is NEVER going to behave that way.

And what if you have, say 3 lines of code, ifdefed out. Not only function calls (those can be ifdefed in a header file) but also assignments? Should those 3 lines be moved to a new function, that would be ifdefed away in its header?