There was a communal baseball bat in my previous office for a similar
purpose. =^)
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 20, 2003 11:37 PM
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
Buffer
>
> We have a daily build which starts at 2:30 am and is supposed to yield
a
> working system the next morning. Whoever breaks the build is supposed
to
> give away donuts to the whole team. We have a daily labeling system
that
> increments the build number every new build, so that our release
engineers
> can recreate any build from that source control label. And long live
> Perforce !
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> Sent: Thursday, November 20, 2003 10:45 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
> Buffer
>
>
> > If the driver is updated often (during Beta stage when you’re
> developing a
> > new board + ASIC for instance), you also get problems with tracking
> which
> > versions of which variation of the driver has which fixes included,
as
> > someone may have updated something during the daily build stage, and
> the
> > second of the builds for that day has a different set of fixes than
> the
> > first build.
>
> These are of course real issues, but there are procedures and
processes
> you can use to alleviate them. For example, having a dedicated build
> engineer; building from a source “snapshot” (so you don’t get builds
> when the source code is in an “intermediate” state); and building all
> binaries during a single build from the source snapshot.
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
This is a great discussion. I wanted to respond to one of Phil’s
comments in particular.
I’m not going to offer anything for Mats, but I can describe one
technique
to ameliorate the first two of the three: Init-time specialization.
That means that you abstract the hardware differences across a common
interface, then you implement a separate module for each hardware
variant
against that interface. At init time, you select the module that
matches
the hardware, pop the function pointers into your dispatch table, and
then
just call them unconditionally when you need them. No run-time
decisions
required. In fact, that’s pretty much what the various miniports do,
but
the miniport loads first, and the common part (the port) is linked to
it by
the loader. The technique I described is the same thing, only you are
doing
the linking explicitly, instead of letting the OS do it for you.
This is definitely preferrable to a labyrinth of if’s. However, for
purposes of this discussion (and to indulge my nit-picky tendencies) I
consider function pointers (including DLL function calls) a form of
run-time conditional in this case, as compared to the compile-time
alternative that has no indirection. I will go even further and be so
bold as to venture that no code that contains certain run-time decisions
can ever be as efficient as the same code with those decisions compiled
in (formal proof left as an exercise for the reader). Of course when
speaking of video driver miniports, this is moot, as Mats points out you
can throw the fattest miniport at me and I’ll still be able to play Half
Life.
Thanks to everyone for your highly informative and educational
responses.
Chuck
Lou Perazzoli from Windows core OS team told that the build breaker was
obliged to wear the goat horns while at work 
(source: "The Microsoft Secrets).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Chuck Batson”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 20, 2003 8:24 PM
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon Buffer
> There was a communal baseball bat in my previous office for a similar
> purpose. =^)
>
> Chuck
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, November 20, 2003 11:37 PM
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
> Buffer
>
>
> >
> > We have a daily build which starts at 2:30 am and is supposed to yield
> a
> > working system the next morning. Whoever breaks the build is supposed
> to
> > give away donuts to the whole team. We have a daily labeling system
> that
> > increments the build number every new build, so that our release
> engineers
> > can recreate any build from that source control label. And long live
> > Perforce !
> >
> > Alberto.
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> > Sent: Thursday, November 20, 2003 10:45 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
> > Buffer
> >
> >
> > > If the driver is updated often (during Beta stage when you’re
> > developing a
> > > new board + ASIC for instance), you also get problems with tracking
> > which
> > > versions of which variation of the driver has which fixes included,
> as
> > > someone may have updated something during the daily build stage, and
> > the
> > > second of the builds for that day has a different set of fixes than
> > the
> > > first build.
> >
> > These are of course real issues, but there are procedures and
> processes
> > you can use to alleviate them. For example, having a dedicated build
> > engineer; building from a source “snapshot” (so you don’t get builds
> > when the source code is in an “intermediate” state); and building all
> > binaries during a single build from the source snapshot.
> >
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com