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. > 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. > 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. :-) > 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. > 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/
