>I want to begin writing Kernel mode driver for Windows NT/Win2K, what should
I know and understand before I begin?
I good thing to know is EXACTLY what interface you want the driver to
present to user-mode. Often, I find my clients make hardware, and have no
idea how they would like the device to look to software. For example, one
device I know could be presented as:
-
a read/write interface to a memory window, with user mode code
understanding what’s where, and issuing read/write commands to the correct
“memory” addresses
-
an interface of many IOCTL’s, with the driver knowing how to make each
one happen in the hardware, these are logical commands, like do some
specific operation
The choice comes down to: what should run in kernel mode, and what in user
mode. The simple memory window interface may work just fine, with a user
mode DLL providing a higher level API to applications. I might actually
argue that as little kernel mode code as possible should be used, as bugs
in kernel mode kode can bring down your system. Bugs in user-mode code are
much less dangerous to the overall system stability. On the other hand,
design #2 may be able to do things that are impossible with design #1, or
do them better/faster.
Some standard devices have the interface predefined, if you make a video
card it’s pretty well defined what interface the driver must present.
Actually, my belief is the OS should have provided a clear definition of
how devices should talk to apps, in a very consistent manner. In reality,
we have a bunch of unique interface definitions. To me, reading a network
packet, or a disk sector, or a live video capture frame, or a response from
your smart card, are not really all that different, yet each of these has a
pretty different interface from an application point of view.
It’s often quite tricky to even figure out exactly what style of driver is
“most” appropriate. For example, I’ve been working on a WDM Pnp function
driver. I keep debating if it would have been better to be a bus filter
driver thingy, due to the legacy interface it has to present to apps.
What methodology should I follow?
That’s a religous question, and I tend to avoid discussing religion on the
Internet. I find methodology is influenced by available programming
languages, and since the driver language choices are C or C (some will
argue C++ works too, and assembler fragments are good sometimes too), your
design methodology choices is also limited.
Is their any specific development cycle I need to follow?
Sure…
Step 1, swear about Microsoft’s kernel debugger a bunch now, as you will
want to when it’s more productive to keep your cool.
Step 2, tell the marketing people they probably should have considered
driver development time in the product delivery schedule BEFORE scheduling
all the marketing glitz
Step 3, take a vacation NOW, as you will not get one after you start
Step 4, write the driver
Step 5, test the driver,
Step 6, beta test the driver with customers who don’t mind their system’s
crashing
Step 7, repeat steps 4 through 6 until your budget is used up
Step 8, disclaim any knowledge about the project, to deflect the criticism
that will occure because the driver still has bugs or is too slow after
using up all the assigned budget
Step 9, go to step 1 for the next project, which may be the next version of
the driver you just wrote
Is there any standard test process I need to go about?
Some devices have test programs available. Use these. There are also some
generic test programs for a variety of things (like how does you driver
respond when all memory is used up). Also test on SMP systems, with a
variety of hardware configurations (like bus bridges). You do own SMP
systems? And systems with bus bridges?. And have a bunch of peripheral
configurations? Customers frown when they have this weeks #1 selling
whatever, and YOUR device+driver conflicts with it.
Any inputs or pointers will be highly appreciated…
Sign up for this list, and join us sometimes happy and sometimes frustrated
driver writers. There is a HUGE amount of knowledge among the list members,
and sometimes list members will share that knowledge on days when not too
many things went wrong.