Gettinng started with Linux drivers

[Amit Uttamchandani]

On Sat, 11 Apr 2009 03:00:13 -0700
Stefan Richter <stefanr at s5r6.in-berlin.de> wrote:

> Amit Uttamchandani wrote:
> > I come from a python background and recently I've been wanting to start
> > writing drivers for Linux. I looked at several different resources (A
> > bunch of docs written by GKH, JCorbet, and etc.) and they have been of
> > great help.
> 
> Yep, to me too.
>

Good to know I'm refering to the right docs ;)
 
> > However, I have some questions which were not really
> > answered. Any help would be greatly appreciated.
> >
> >  1. I am familiar with C but have never really written a driver. What
> > are the guidelines? Meaning, what are best practices on how to write
> > these drivers. Specifically, what should go in header .h files and what
> > should not (Maybe that's more related to generic C programming...).
> > When is it appropriate to place them in /usr/include instead of the
> > driver folder.
> 
> Code which will be compiled into object code does not go into headers
> but into .c files (function definitions, string constants etc.).  OTOH,
> function prototypes, preprocessor macro definitions, definitions of
> small static inline functions etc. can go into headers.
> 
> If your driver does not export functions or variables to be called/
> accessed by other drivers, you actually don't need a header.  In that
> case, use a header file only if you have a lot of macros to define (e.g.
> for named register offsets and register contents).  Such headers which
> are not meant to be included by any other file than a single xyz.c are
> sometimes called something like "xyz-private.h".
> 
> If you export something to other drivers in the same subdirectory, put
> the header file into the subdirectory.
> 
> If you export something for other drivers anywhere across the linux
> source tree, put the header into linux/include.  (Exception:  Some
> subsystems don't do this; their users have to add respective search
> paths into their Makefiles.)
> 
> If you export an API to userspace, put the header into linux/include and
> register it as a header to be installed into /usr/include.
> 

Thanks for the great explanation! This really made things a lot
clearer. Now I feel I can move in the right direction.

> >  2. What about debugging drivers? I have read a bunch of docs talking
> > about gdb, kdbg, etc. But again what are best practices here?
> 
> I personally never used any debugger, just printk and the various nice
> options in the kernel hacking configuration menu.  Maybe I have been
> missing out on something which only debuggers provide, but lucky me, I'm
> unaware of it. :-)
> 

Let's hope I'm as lucky.

> >  3. How do I know if a driver has already been written? Right now, I
> > simply do a grep -R trying to match several device name strings.
> 
> Usually, drivers are matched against some numeric IDs.  Many if not most
> drivers contain module aliases in their .ko so that they are auto-loaded
> if the respective hardware is found.
> 
> However, maybe a driver was written but not yet submitted to the
> mainline.  Open-source out-of-tree drivers are listed at
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers .
> 

This is a good source. The page is updated frequently.

> You could also ask on the relevant subsystem mailinglist if anybody
> knows of a driver for your specific device which is not in the mainline.
> 

Is there a list of sub-system maintainers? Or do I search for them in
the git commit logs?

> >  4. Tips on how to get started? I have read several example drivers but
> > are there any 'platinum' class drivers that you can recommend that is
> > clear and that you recommend regularly to beginners. (Specifically
> > networking phy drivers in my case.)
> 
> I'm not familiar with networking.  Generally, old drivers --- even if
> still actively maintained --- may contain code which does not reflect
> currently preferred coding practices.  Hence you should rather look at
> newer drivers.  But not at those in linux/staging/. ;-)

Thanks for the tip. For the drivers you are familiar with, anything
that you would recommend?

> --
> Stefan Richter
> -=====-=-=== -=-= -==-=
> http://arcgraph.de/sr/
> 

Amit