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
