Martin O’Brien wrote:
Assuming you don’t mean filter or something like that, in my opinion,
just use a NT4 style driver.
Yes, no hardware involved. I’ve recently downloaded the latest KMDF
SDK. Does that have all I need for writing an NT4 style driver and
signing it etc for use under 64bit Vista? Could you recommend a
good sample and maybe tutorial to start me off? Probably I’m not
looking long term at writing drivers. I just have the one case
I need to solve.
Cheers,
Paul.
Actually, in the context below I mean a kernel extension for some purpose.
Typically this is where there is a documented kernel way of doing
something, that there is not a documented user space mechanism for.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> What exactly do you mean with ‘software only driver’, does that include
> filter drivers ?
>
> /Daniel
>
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> Actually, I still write a number of software only drivers with the
>> legacy model. I rarely can find justification for a software only driver
>> to be anything other than legacy (note the rarely, this is not an
>> absolute). But if you are dealing with real hardware I would definitely
>> go with KMDF or UMDF.
>>
>>
>> –
>
>
Paul,
A good sample is the general\event driver in the current WDK. The WDK
has everything you need to build this type of driver. These drivers
typically just use read/write/ioctl to communicate with user space, and do
some specific task that is easier to do in the kernel.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Paul Gardiner” wrote in message news:xxxxx@ntdev…
> Martin O’Brien wrote:
>> Assuming you don’t mean filter or something like that, in my opinion,
>> just use a NT4 style driver.
>
> Yes, no hardware involved. I’ve recently downloaded the latest KMDF
> SDK. Does that have all I need for writing an NT4 style driver and
> signing it etc for use under 64bit Vista? Could you recommend a
> good sample and maybe tutorial to start me off? Probably I’m not
> looking long term at writing drivers. I just have the one case
> I need to solve.
>
> Cheers,
> Paul.
>
>> 2) The giant support binary adds a lot of bloat that may be unexepcted
> and undesirable for size sensitive distributions.
The bloat is amortized over all KMDF drivers and can be ignored. This is
not 1990. PCs have gigs of >ram and 100s of gigs of disk space. Bloat? See
vista. Bloat is so 20th century.
This is not an entirely complete analysis of the impact of the ‘bloat’.
Sure it is not problem to have a single copy of the KMDF on the system (in
fact, it is likely that all systems will shortly have a single copy of the
KMDF on them).
However, for software that is distributed over channels with less than the
limitless bandwidth *we* all enjoy (right?) having to cart along 3+mb of
coinstaller is painful. In fact, a customer of mine has asked that a
perfectly good, stable, and otherwise fine KMDF driver that I created for
them be scrapped and rewritten as a WDM driver simply because it blows the
download budget out of the water for their system.
It sure would be nice to have some solution which has a much lower
distribution footprint and only gets the *actual* framework if necessary
(perhaps via download).
But on-disk cost? Sure, burn it up. Seagate will rise to the challenge…
Dave Cattley
Consulting Engineer
Systems Software Development
We have received this feedback (being able to download the bits via the
coinstaller to reduce initial size) and we are trying to see if we can
create a viable solution.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Sunday, June 10, 2007 7:19 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reasons NOT to use KMDF
> 2) The giant support binary adds a lot of bloat that may be
unexepcted
> and undesirable for size sensitive distributions.The bloat is amortized over all KMDF drivers and can be ignored. This
is
not 1990. PCs have gigs of >ram and 100s of gigs of disk space. Bloat?
See
vista. Bloat is so 20th century.
This is not an entirely complete analysis of the impact of the ‘bloat’.
Sure it is not problem to have a single copy of the KMDF on the system
(in
fact, it is likely that all systems will shortly have a single copy of
the
KMDF on them).
However, for software that is distributed over channels with less than
the
limitless bandwidth *we* all enjoy (right?) having to cart along 3+mb of
coinstaller is painful. In fact, a customer of mine has asked that a
perfectly good, stable, and otherwise fine KMDF driver that I created
for
them be scrapped and rewritten as a WDM driver simply because it blows
the
download budget out of the water for their system.
It sure would be nice to have some solution which has a much lower
distribution footprint and only gets the *actual* framework if necessary
(perhaps via download).
But on-disk cost? Sure, burn it up. Seagate will rise to the
challenge…
Dave Cattley
Consulting Engineer
Systems Software Development
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
In my experience, it boils down to what who you are communicating with.
If it is a dedicated app, then a legacy style driver is fine. If there
is some other component that has other requirements (like the arrival of
a device interface), a pnp stack is required.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Paul Gardiner
Sent: Sunday, June 10, 2007 1:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Reasons NOT to use KMDF
Don Burn wrote:
Actually, I still write a number of software only drivers with the
legacy
model. I rarely can find justification for a software only driver to
be
anything other than legacy (note the rarely, this is not an absolute).
But
if you are dealing with real hardware I would definitely go with KMDF
or
UMDF.
I’ve been wondering that all through this thread. I have to write a
software only driver. Should I use legacy or KMDF? It has to work
under 64bit Vista - only under 64bit Vista.
Cheers,
Paul.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Sorry to have brought up the bit about UMDF not working in 2003, but that’s actually what inspired this thread–it was a gotcha I never knew about and wondered about KMDF limits I might not know about. So KMDF is perfectly fine for boot start drivers–excellent news. But as others confirmed, the large distribution size can be a negative or even a show stopper.
I wonder why not all examples in the WDK are KMDF. It appears the entire storage stack doesn’t use it at all for instance. You would think that if this is really the way to go, Microsoft would lead by example, even if it cost them extra time because it would set the stage for all new driver developers to follow.
eof
The answer to that question is simple. Most of the storage stack does not
have any PnP or Power processing in it. The port drivers supply all the PnP
& Power logic required for their miniports. There is some indication that
some of the miniports will have a KMDF framework in the future, and a few
might work now if rewritten properly. There have been a few posts about how
to use KMDF to write drivers that use WDM lower edge.
Most of the samples in the WDK were written by third parties. While I think
the original floppy driver was written by Microsoft I heard a third party
did the split of floppy.sys into two drivers. Some of the samples are from
third party companies. If you mean disk.sys and cleanup.sys in the storage
stack they are the disk class drivers. Cleanup.sys is the PnP and power
support for disk.sys and I think other class drivers from Microsoft also use
it.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
wrote in message news:xxxxx@ntdev…
> Sorry to have brought up the bit about UMDF not working in 2003, but
> that’s actually what inspired this thread–it was a gotcha I never knew
> about and wondered about KMDF limits I might not know about. So KMDF is
> perfectly fine for boot start drivers–excellent news. But as others
> confirmed, the large distribution size can be a negative or even a show
> stopper.
>
> I wonder why not all examples in the WDK are KMDF. It appears the entire
> storage stack doesn’t use it at all for instance. You would think that if
> this is really the way to go, Microsoft would lead by example, even if it
> cost them extra time because it would set the stage for all new driver
> developers to follow.
>
> eof
>
>
While there are a few samples owned by 3rd parties, most are owned by
Microsoft. The KMDF does not own all of the samples though, they are
owned by teams all across the company. Remember that KMDF is a
relatively new technology and some of these samples are quite mature and
the owning teams have not yet had a chance to move over where
appropriate. Where appropriate is the key term here, David touched on
this. The storage stack has some strict requirements, especially at the
lower layers and KMDF does not meet all of these requirements (which,
BTW, do not show up in a regular driver). For other stacks (video, KS,
etc), KMDF does not make much sense since there is an existing port
driver which takes care of most of what KMDF does. OTOH, samples which
are duplicated in both WDM and KMDF will be KMDF only in the future and
other WDM samples will be moved over as the owning teams have the time
and inclination to convert them.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Sunday, June 10, 2007 10:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Reasons NOT to use KMDF
The answer to that question is simple. Most of the storage stack does
not
have any PnP or Power processing in it. The port drivers supply all the
PnP
& Power logic required for their miniports. There is some indication
that
some of the miniports will have a KMDF framework in the future, and a
few
might work now if rewritten properly. There have been a few posts about
how
to use KMDF to write drivers that use WDM lower edge.
Most of the samples in the WDK were written by third parties. While I
think
the original floppy driver was written by Microsoft I heard a third
party
did the split of floppy.sys into two drivers. Some of the samples are
from
third party companies. If you mean disk.sys and cleanup.sys in the
storage
stack they are the disk class drivers. Cleanup.sys is the PnP and power
support for disk.sys and I think other class drivers from Microsoft also
use
it.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
wrote in message news:xxxxx@ntdev…
> Sorry to have brought up the bit about UMDF not working in 2003, but
> that’s actually what inspired this thread–it was a gotcha I never
knew
> about and wondered about KMDF limits I might not know about. So KMDF
is
> perfectly fine for boot start drivers–excellent news. But as others
> confirmed, the large distribution size can be a negative or even a
show
> stopper.
>
> I wonder why not all examples in the WDK are KMDF. It appears the
entire
> storage stack doesn’t use it at all for instance. You would think that
if
> this is really the way to go, Microsoft would lead by example, even if
it
> cost them extra time because it would set the stage for all new driver
> developers to follow.
>
> eof
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> However, for software that is distributed over channels with less than the
limitless bandwidth *we* all enjoy (right?) having to cart along 3+mb of
coinstaller is painful. In fact, a customer of mine has asked that a
perfectly good, stable, and otherwise fine KMDF driver that I created for
them be scrapped and rewritten as a WDM driver simply because it blows the
download budget out of the water for their system.
This is extremely rare case. 3MB for the modern age of DSL is nothing.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> the original floppy driver was written by Microsoft I heard a third party
did the split of floppy.sys into two drivers.
This started from w2k to support floppy-attached tapes. Was it a 3rd party
work?
third party companies. If you mean disk.sys and cleanup.sys in the storage
ClassPnP.sys is the common code for both Disk and CdRom, it is not only
PnP/Power, it is read/write too 
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Don Burn wrote:
A good sample is the general\event driver in the current WDK. The WDK
has everything you need to build this type of driver. These drivers
typically just use read/write/ioctl to communicate with user space, and do
some specific task that is easier to do in the kernel.
Brilliant! Thanks. That does look to be an ideal starting place. I’ll
see if I can manage to build it and install it on my machine. I seem
to remember seeing it said in this list before that 64bit Windows
will accept only signed drivers, but you can set it to allow
self signed certificates. I should still have all those messages.
I shall have a search through my mailbox.
Cheers,
Paul.
If you’re connected to WinDbg, then this is not a concern. Otherwise,
press F8 early during boot, and select the appropriate option.
mm
>> xxxxx@glidos.net 2007-06-11 07:47 >>>
Don Burn wrote:
A good sample is the general\event driver in the current WDK. The
WDK
has everything you need to build this type of driver. These drivers
typically just use read/write/ioctl to communicate with user space,
and do
some specific task that is easier to do in the kernel.
Brilliant! Thanks. That does look to be an ideal starting place. I’ll
see if I can manage to build it and install it on my machine. I seem
to remember seeing it said in this list before that 64bit Windows
will accept only signed drivers, but you can set it to allow
self signed certificates. I should still have all those messages.
I shall have a search through my mailbox.
Cheers,
Paul.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
From one of Steve Cleary’s posts:
>
Slightly off-topic: are there .ctl files for the KMDF WPP logs? I tried to grab the logs using tracelog/traceview, but there doesn’t seem to be enough information provided with the KMDF to make this possible. So I had to set up WinDbg with a remote debugging session, etc., which seems a bit of overkill just to watch some trace statements… I saw on various newsgroups that others had the same problem.
<<
?? On Vista and up, anyway, the provider is registered with ETW- so you can use traceview (which supports “registered providers”- see its WDK documentation), pick it from the list of named providers [“KMDFv1 Trace Provider”], and point to the same TMF File you use for the kernel debugger.
On back-level, you can manually enter the GUID {544d4c9d-942c-46d5-bf50-df5cd9524a50}. I’m not aware of any CTL files- that may be hole in the product offering- I’ll take that up with the group…
I HATE to hijack this thread even further, but something Anton said bothers me and is very dangerous to leave in the archives:
Sorry, but either I misunderstand what you’re saying or this IS NOT CORRECT.
For WDM: If you supply a completion routine, and if Irp->PendingReturned is set and you do not reclaim the IRP, then you MUST call IoMarkIrpPending in your completion routine.
This has been true since the dawn of NT time.
While IoCompleteRequest DOES call IoMarkIrpPending, it only does so if you DO NOT supply a completion routine.
If I misunderstand what you’re saying, please correct me – feel free to contact me off list.
Peter
OSR
Maxim wrote:
David R. Cattley wrote:
> However, for software that is distributed over channels with less
> than the limitless bandwidth *we* all enjoy (right?) having to
> cart along 3+mb of coinstaller is painful. In fact, a customer
> of mine has asked that a perfectly good, stable, and otherwise
> fine KMDF driver that I created for them be scrapped and rewritten
> as a WDM driver simply because it blows the download budget out
> of the water for their system.This is extremely rare case. 3MB for the modern age of DSL
is nothing.
No, it is not “extremely rare” at all. Several people on this thread have pointed it out as a customer complaint and I’ve heard it from my customers as well.
I think people are used to (in my case, USB) drivers being ~50K or so. The average MSI with installer executable, documentation, etc. is almost two orders of magnitude larger.
Doronh said a statically linked KMDF .sys would start at 500K, I find that difficult to accept, wouldn’t the linker throw away unused imports/symbols, etc.?
Martin O’Brien wrote:
If you’re connected to WinDbg, then this is not a concern. Otherwise,
press F8 early during boot, and select the appropriate option.
Once I really did follow the directions in the document, I found the
test signing method to be the easiest. That way, I don’t have to
remember to take some action at every boot.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
What document, Tim? I’d be most interested in this as well.
>> xxxxx@probo.com 2007-06-11 15:23 >>>
Martin O’Brien wrote:
If you’re connected to WinDbg, then this is not a concern.
Otherwise,
press F8 early during boot, and select the appropriate option.
Once I really did follow the directions in the document, I found the
test signing method to be the easiest. That way, I don’t have to
remember to take some action at every boot.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hard to fathom, but true. There are enough weak cross references in the
objects that you pull in most of the other objects code. For instance,
while you may not use DMA, the power state machine does have a
pontetially valid pointer to the DMA code so that you get the
appropriate callbacks on power up/down.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, June 11, 2007 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reasons NOT to use KMDF
Maxim wrote:
David R. Cattley wrote:
> However, for software that is distributed over channels with less
> than the limitless bandwidth *we* all enjoy (right?) having to
> cart along 3+mb of coinstaller is painful. In fact, a customer
> of mine has asked that a perfectly good, stable, and otherwise
> fine KMDF driver that I created for them be scrapped and rewritten
> as a WDM driver simply because it blows the download budget out
> of the water for their system.This is extremely rare case. 3MB for the modern age of DSL
is nothing.
No, it is not “extremely rare” at all. Several people on this thread
have pointed it out as a customer complaint and I’ve heard it from my
customers as well.
I think people are used to (in my case, USB) drivers being ~50K or so.
The average MSI with installer executable, documentation, etc. is almost
two orders of magnitude larger.
Doronh said a statically linked KMDF .sys would start at 500K, I find
that difficult to accept, wouldn’t the linker throw away unused
imports/symbols, etc.?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@gmail.com wrote:
Doronh said a statically linked KMDF .sys would start at 500K, I find that difficult to accept, wouldn’t the linker throw away unused imports/symbols, etc.?
It depends on how KMDF is written. It’s C++ code. If it was written in
a pseudo-COM manner, using interfaces and virtual functions, then the
virtual functions will get linked in whether they are used or not,
because they are referenced by the vtbl.
Also remember that even a basic KMDF driver brings into play most of the
major KMDF subsystems: dispatching, power, plug-n-play, queues,
collections, driver objects, device objects, IO targets.
The whole WDF helper driver is 490k, so 500k is probably a pretty good
estimate.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.