It is really each team’s decision on how they deploy, release and test their driver models for each and across OSs and really, the biggest determining factor, their business models. That is part of the reason why we created WDF, which was to unify some of these models over time and when new device silos were created, standardize on WDF. I still don’t understand the argument. Are you saying that just b/c that is the way it was before KMDF arrived, we should have kept with tradition? Or that once we broke with tradition everyone should have followed WDF?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, December 22, 2009 10:59 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.
What I am saying is that your decision to separate KMDF from OS
releases just complicates things.
Why not have all the other container drivers, scsiport, storport,
ndis, etc also have their own coinstallers, independent releases,
etc.?
Mark Roddy
On Tue, Dec 22, 2009 at 1:48 PM, Doron Holan wrote:
>> Has any kmdf release changed an interface?
> Define change ;). ?There have been bugfixes where we tightened the contract ?and we felt it was OK to do so after extensive testing and review. ?We have extended what objects can do (counted and fwd progress queues for instance) which also are interface changes. ?In general, once created, the implementations stay the same over time, we aggressively try to avoid wholesale rewrites underneath the covers. ?Too much risk for changing the contracts accidentally when doing that. Imho, If we were to go down the rewrite path for whatever reason, that would be cause for a new major version number so that we do not adversely affect existing client drivers in the field.
>
>> New interfaces should follow the windows release model and be restricted to major releases.
> Major releases of what? The OS? The framework? ?Wdf treats the major number as the compatible line in the sand. ?If we want to change the way things work wholesale, we would change the major version number. Minor version numbers are used to define new objects and new behaviors that are backwards compatible with existing ones in the same major version
>
>> Developers would and should develop for kmdf as they do for os releases. Separating kmdf from os releases was and is problematic.
> Why? ?That is not what our customers are telling us through surveys and in person interviews (and this is with 100s of data points, so it is not like I am cherry picking results). ?We get overwhelmingly positive feedback that a dev can use new features downlevel and have one programming model across OS releases, rather than attempting to avoid features based on the OS you are running on
>
> d
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Tuesday, December 22, 2009 1:50 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.
>
> Has any kmdf release changed an interface? I thought the point was bug
> fixes. New interfaces should follow the windows release model and be
> restricted to major releases. Developers would and should develop for
> kmdf as they do for os releases. Separating kmdf from os releases was
> and is problematic.
>
> On Monday, December 21, 2009, Maxim S. Shatskih wrote:
>>> Can I ask why KMDF seems to be in some sort of different category than other
>>> driver run-time DLL’s like storport or ndis? Since as IHV’s, we don’t get
>>> any control over what version of KMDF our driver will be executing under, I
>>> don’t know why you just don’t roll it into a critical update and service
>>> pack.
>>
>> Well, this is really a good idea.
>>
>> It has its drawbacks though - if you will write the driver to a new framework, then you will need the particular WU patch to be installed before installing a driver, which is not always good.
>>
>> The design goals under MS’s decision on KMDF versioning are 1) easy patching of KMDF issues, including security ones, with static linking this would be impossible 2) the ability for a driver written for new KMDF to install on a machine with the old KMDF.
>>
>> As about SxS KMDF - Doron have explained everything.
>>
>>> with special driver J fixes). SxS also solves the issue of I plug in a new
>>> USB device, that requires 1.9, but 1.7 is in use, so a reboot would be
>>> required.
>>
>> Probably MS will solve this issue by rolling the Windows Update patch which will upgrade all KMDF binaries in all Windows versions in the world to 1.9.
>>
>> After such a thing, the installation of 1.9 driver will not require a reboot.
>>
>> Probably such an idea would be even better then to ship the KMDF install package (in a coinstaller DLL) with each driver. Probably it would be better to ship the WU package with a KMDF update instead of such a DLL.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> 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
>>
>
> –
> Mark Roddy
>
> —
> 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
>
>
> —
> 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
>
—
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