The Old Joel on Software Forum: Part 4 (of 5)

Device driver

Hi ,
I am new to device drivers and i want to write a device driver for pcmcia card for the os windows 2000. we are using this card for capturing wlan frames. Can any one help me where to start with. I have installed visual c++ and ddk.

suresh
Thursday, April 22, 2004

Start by looking at the DDK examples and documentation. There's a lot there.

There's a couple of good books on WDM driver development. Amazon.Com has them all.

Here's a good site to visit for help: http://www.osronline.com/ The people on the OSR mailing lists are very knowledgable and helpful.

Learning the DDK can be pretty scary at first. You may want to look at a third party driver development toolkit. I highly reccomend DriverWorks from Compuware. You could also look at Jungo WinDriver, but you may run into performance issues.

Myron A. Semack
Thursday, April 22, 2004

If you're also new to hardware you might want to get your feet wet with a software only driver. I'm not a windows guy, but on linux I give people the following spec:

Write a driver that associates with a major device number. When read it identifies the minor number, and returns the requested number of the minor number. When written, it compares the provided buffer with the minor number and returns 0 if they match, -1 otherwise. Minor number 0 is a special case. Reading minor 0 returns a sequence of bytes, 0, 1, ..., 254, 255, 0, ... Writing 0 compares the provided buffer with the expected sequential result. If the device is opened multiple times, each instance maintains it's own sequence.

What all that means is that if you open /dev/mydriver4, then issue read(fd, mybuf, 6); you get back 6 4's. write(fd, mybuf, 6) returns 0. wrire(fd, mybuf, 7) will probably return -1.

Opening /dev/mydriver/0, read(d, mybuf, 3) gives 0, 1, 2. Another read returns 3, 4, 5. write(fd, mybuf, 3) returns 0 if mybuf contains 0, 1, 2.

This gets you familiar with building/installing/removing drivers, accessing the filesystem, maintaining state, and determining which process is calling your driver. It turns out to be surprisinging helpful for people who have never written a driver before. Even better, 90% of the code they crank out will be used in the "real" driver as well.

Snotnose
Thursday, April 22, 2004

Get a serious talk with someone who has experience writing device drivers. Drivers, and kernel-level programming in general, is very different from "userland" coding, because things that look like small mistakes (or not even mistakes) in userland often take the whole machine down.

Examples off the top of my head:

- Limited stack space (12k on Win2k, if I'm not mistaken - that's NOT much) - which means recursion is often intolerable, and that local variables (!) have to be used with extreme care; e.g., a local int x[8192] will blue screen.

- Often forced to use asynchronous techniques (in many contexts, you're not allowed to block waiting for an answer)

- Some operations allowed only in limited contexts (e.g., access to a paged-out pages is not allowed in interrupt contexts).

- Timing limits - e.g., must not hold spinlock more than a few microseconds.

Many C++ constructs do not play well with kernel mode - exception propogation, while possible, is hard to do properly. Dynamic memory allocation is not available in all contexts -- thus, abstraction is problematic (you can't use it in interrupt context unless you know it's all stack based, for example - forget about STL containers or strings for that).

Kernel programming is something that's _very_ hard to learn on your own while doing your first commercial project -- especially if coming from an application world.

Ori Berger
Thursday, April 22, 2004