Amit Uttamchandani wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
>  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. :-)

quoted text
>  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 .

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.

quoted text
>  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/. ;-)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel