New to Linux Kernel/Driver development

Question

Recently, i began developing a driver of an embedded device running linux.

Until now i have only read about linux internals.
Having no prior experience in driver devlopment, i am finding it a tad difficult to land my first step.

• I have downloaded the kernel source-code (v2.6.32).
• I have read (skimped) Linux Device Drivers (3e)
• I read a few related posts here on StackOverflow.
• I understand that linux has a "monolithic" approach.
• I have built kernel (included existing driver in menuconfig etc.)
• I know the basics of kconfig and makefile files so that should not be a problem.

Can someone describe the structure (i.e. the inter-links)
of the various directories in the kernel-source code.

In other words, given a source-code file,
which other files would it refer to for related code

(The "#include"-s provide a partial idea)

Could someone please help me in getting a better idea?
Any help will be greatly appreciated

Thank You.

Answer 1

Given a C file, you have to look at the functions it calls and data structures it uses, rather than worrying about particular files.

There are two basic routes to developing your own device driver:

• Take a driver that is similar to yours; strip out the code that isn't applicable to your device, and fill in new code for your device.
• Start with the very basic pieces of a device driver, and add pieces a little at a time until your device begins to function.

The files that compose your driver will make more sense as you complete this process. Do consider what belongs in each file, but to some extent, dividing a driver among files is more an art than a science. Smaller drivers often fit into just one or two files.

A bit of design may also be good. Consider what you device does, and what your driver will need to do. Based on that, you should be able to map out what functions a device driver will need to have.

I also believe Linux Device Drivers, Third Edition may help you get on your way to driver development.

Linux files themselves include files based on what they do, what layer they are in, and what layer they access of the call stack. The Big Picture truly informs how each file is related to the next.