Version-control of firmware and assoc. device drivers

NTDEV
1

Hi,

I am maintaining the firmware and associated device driver (KMDF) for a
CAN-USB-Ethernet-device.

The device driver for CAN-USB is just about to qualify for WHQL.

To ease the maintenance further on - as the device enters the market - I need some advice how to avoid possible revision-control nightmares before the driver is released.

The company is using Subversion, but I believe that some of the questions are universal.

Questions regarding revision control

Firmware is pre-loaded during manufacturing process

  1. Should the USB-REV-identifier match the revision number of the firmware repository?
    Drawbacks / Pros (trace Winqual / WER-reports to specific firmware
    revisions)?

  2. What are the drawbacks with the following directory layout?
    Any additional recommendations (should objfre_… be kept outside revision control, what about pdb-files)?

±- trunk
----+ firmware
----+ winkmdf
--------+ objfre_win7_x86\i386
--------+ objfre_win7_x64\amd64
----+ winapp

  1. Should the firmware and the driver be put into a common repository, even if they do not share any source code files
    (so that both the firmware and the driver get the same revision number at RTM)?

  2. Should the INX-file be included into the repository?
    Any special actions to prevent stampinf / WHQL-signature from interfering with revision control?

Firmware is loaded by the device driver
(the firmware is placed as a resource-blob into the sys-file).

  1. Should the .rc-script include an explicit reference to the latest
    output-binary from the embedded-C-compiler (so that both the firmware and the driver can be built in a sequence)?

5b. … or should I manually copy the firmware binary from the
embedded-C-output to the winkmdf-directory?
How do I keep track of the firmware revision that was included in the output sys-file?

Andreas Nilsson

2

The answers to all of your questions are obviously all opinions and I’m not sure that some of them have a ‘general’ answer; most really depend on how your team in practice works.

  1. I have no idea - I just don’t enough about USB to comment intelligently here.

  2. Personally, I’m a believer in putting build products (as well as build tools, where legally possible) under scm, though this is far from a universal practice. That being said, due to the way that PDB’s are identified, I think that not preserving them (and the matching binaries) is asking for trouble down the road.

I’m a fan of separate source and build trees, but that too is an opinion. Getting that to happen under a WDK BUILD environment takes some work, and without directly copying/moving files after ‘build’ completes, it’s not possible (as best as I can tell) to not have the build products placed in a directory structure that I deeply hate. So I copy and move them.

  1. My first instinct would be to place them in the same repository, but here again, this really depends on how your place of business works.

  2. Regarding whether the inx file should be put under scm, absolutely; regarding the stampinf bit, I’m not really sure what you mean/what you’re worried about.

  3. I would have some sort of staging directory (in a separate tree), but I’m not really sure why it matters enough to worry about it at this point.

That is - in general - why are all these questions coming up now? Another way of saying it is why aren’t you just going to continue to do what you’ve already been doing?

Good luck,

mm

3

My general concern is to get it all in proper order before the device enters the market, to ease future maintenance and crash-dump analysis.

Especially, to ensure that Windbg will locate the proper source code revision associated with the crash-dump if the .pdb-files are kept in symstore (out of scm).

Regarding stampinf:

I did put a $Id-tag as a remark inside the INX-file to keep track of configuration data in AddReg-directives.

I invoked stampinf and inf2cat to sign the package. No problems.
However, the scm changed the $Id-tag of the INF-file too, invalidating the signature, as I commited the changes.

That’s why I am unsure if scm is a suitable place for driver packages & its pdb-files.
Or, if I just need to reconfigure the scm in a better way.

Andreas Nilsson

4

If you want to strip out $Id when compiling your .INF then you need a more complicated system than stampinf.

Another option is to store the signed and sealed driver package on a different server, for example indexed by SVN branch and revision.

Any other schemes?
Tim Green

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-410353-
xxxxx@lists.osr.com] On Behalf Of xxxxx@live.se
Sent: 05 May 2010 16:18
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Version-control of firmware and assoc. device drivers

My general concern is to get it all in proper order before the device enters
the market, to ease future maintenance and crash-dump analysis.

Especially, to ensure that Windbg will locate the proper source code
revision associated with the crash-dump if the .pdb-files are kept in
symstore (out of scm).

Regarding stampinf:

I did put a $Id-tag as a remark inside the INX-file to keep track of
configuration data in AddReg-directives.

I invoked stampinf and inf2cat to sign the package. No problems.
However, the scm changed the $Id-tag of the INF-file too, invalidating the
signature, as I commited the changes.

That’s why I am unsure if scm is a suitable place for driver packages & its
pdb-files.
Or, if I just need to reconfigure the scm in a better way.

Andreas Nilsson

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

I guess what I mean by ‘why now’ is will changing fundamental things like how your scm is organized cause problems with the way things are done and have been done for a while already.

As far as the issue of keeping source, binaries and pdb’s in sync, you will either need to keep everything in scm and handle the mapping yourself, or you’ll need to setup a source server as well as symbol server. I’ve never used the later, but it only works for certain scm’s and svn is one of them. I have no idea of how well/convenient the whole operation is.

There’s a document (srcsrv.doc) about source servers in the ‘srcsrv’ directory of your windbg installation.

Good luck,

mm

6

If you REALLY want to do this “right”… and very conveniently as well… you should check out the Windows Source Server (http://msdn.microsoft.com/en-us/library/ms680641(VS.85).aspx). Using it basically GUARANTEES that you have the right sources for any given build of a product.

VERY cool facility,

Peter
OSR

7

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Wednesday, May 05, 2010 9:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Version-control of firmware and assoc.
device drivers

If you REALLY want to do this “right”… and very
conveniently as well… you should check out the Windows
Source Server
(http://msdn.microsoft.com/en-us/library/ms680641(VS.85).aspx)
. Using it basically GUARANTEES that you have the right
sources for any given build of a product.

VERY cool facility,

Interesting.

We’re using a bit different approach. We have a dedicated build machines
and when build is run, the first action is to download all the necessary
files from SCM archives. Then it creates label for all involved files
named according to build number. Build is run, binaries and PDBs creates
and everything stays at build machine and can be located directly using
project name and build number (which is also in binaries version info).
Both manually giving WinDbg correct paths or using symbol server. Too
old builds are archived and deleted and if really necessary, they can be
recreated using the label. The advantage I see is when I’m searching for
a bug in some build, I have direct access to all binaries and sources
used for given build and there is no space for a mistake, I can search
all sources directly etc. Everything can be done using SCM and label,
too, but it takes more time and work. Especially if more builds are
examined at once. It costs only disk space which is rather cheap
nowadays.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

8

> 1. Should the USB-REV-identifier match the revision number of

the firmware repository?
Drawbacks / Pros (trace Winqual / WER-reports to specific firmware
revisions)?

Depends on your numbering schema. USB revision is bcdDevice field where
BCD part (binary coded decimal) is important. You can’t use whole two
bytes freely, A - F numbers aren’t allowed. You have 0.00 - 99.99 range
and if your marketing likes to play with version numbers, you can be
easily out-of-sync quickly. For example, if you have 1.0 firmware and
want to make more than 9 fixes. Or variants. What if you have 1.0
firmware with variants A and B for different customers? Using 1.01 and
1.02 isn’t a good idea because they aren’t in order, they for example
differ in enabled features which are unrelated to USB.

You can create a simple mapping in a text file (stored in SCM), instead.

  1. What are the drawbacks with the following directory layout?
    Any additional recommendations (should objfre_… be kept
    outside revision control, what about pdb-files)?

IMO SCM should contain everything necessary to build results and nothing
else. Having build results there is an overkill and you’d quickly
overcome any reasonable archive size limit (think about backup). The
exception are build results used for different build. Like libraries
created when building one project and necessary as input for different
one. In our case we store them as packed archives (imports) and not all
but only qualified. Imports are versioned and never changed and/or
branched; we take them as shared repository for all projects.

  1. Should the INX-file be included into the repository?

Sure. It is build input.

How do I keep track of the firmware revision that was
included in the output sys-file?

Firmware is also your build input. In our case I’d create an import
package for it, properly version and store to SCM. In the driver project
configuration I’d add import package with appropriate version and that’s
all. Build extracts all inputs including project configuration so
anytime later I can quickly look there and will see which fw version was
used and can extract it from appropriate import package when necessary.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]