On Sat, 11 Apr 2009 03:00:13 -0700

Stefan Richter  wrote:
> 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.

>

Good to know I'm refering to the right docs ;)
> > However, I have some questions which were not really

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

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

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

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

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

quoted text
> Stefan Richter

> -=====-=-=== -=-= -==-=

> http://arcgraph.de/sr/

> 

Amit
_______________________________________________

devel mailing list

devel@linuxdriverproject.org

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel