Gettinng started with Linux drivers
auttamchandani at canoga.com
Mon Apr 13 01:08:22 UTC 2009
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
> -=====-=-=== -=-= -==-=
More information about the devel