> “diffusing the situation”
This is, in fact, perfectly good English. Am I missing something?
is accused of trying to “bate” people
and THIS is a simple misspelling of “bate” for “bait”… which would make this an otherwise perfectly proper English language phrase. One can hardly blame people for a quick misspelling… this is the Internet, and MY iPad keyboard misspells things all the time. Again, what am I missing?
This is a philosophical debate, and largely depends on what “par” for quality means to those who are debating. But I’ll grant that in SOME cases, an open source project that’s supported by the community COULD not entirely suck. I will save you (and the entire Community) my standard dissertation on the topics of devs “scratching your own itch” and not “doing the dirty and unglamorous work that needs done” on a given project. I’m sure you can imagine what it is. Just insert all that here.
And we have, to this point, exactly zero indication from Microsoft how they’ll be proceeding in this area. Who’s reviewing PRs, what are the criteria for approving them, etc.
MY issues are:
a) For the average dev, who writes one or two drivers *ever* while they work for a given company, I don’t see how something like DMF works to their advantage.
You COULD argue, that once a given dev has learned DMF they could go from company to company throughout their career efficiently writing DMF drivers. Maybe. That assumes DMF is maintained and continues to exist for many years going forward. But it also leads to my second issue.
b) I am not convinced that a driver written using DMF is easier (or even, as easy) to maintain as one written using base WDF and the necessary custom code alone. If the dev above, who learns DMF and writes one driver using it at company A, and another two drivers using it at company B… the devs who come after that DMF-using dev now have to ALSO spend the time to learn DMF and debug through DMF and track the status of the DMF project. And they need to do this on their own. And every time there’s a bug, they have to determine whether the bug is in their device-specific code or in DMF … or, at the very least walk through the DMF code to FIND their bug.
This does not strike me as a win.
c) So now a new dev… who knows a LITTLE WDF… joins company B, which has two DMF-based drivers. Ignoring the learning and debugging burden I describe immediately above: This dev looks at the sources, and instead of saying “Oh, a WDF driver”… sees the driver AND a whole bunch of DMF framework, and wonders “What hath Gxd wrought.” She then needs to determine WHICH version of DMF is being used, WHETHER it’s been forked or whether its in its pristine state.
You may argue, correctly, that this is the state of the world in the Open Source community. And, if you’re using some library like Boost (love it or hate it) to write some random user-mode app… maybe that’s OK.
But this is driver code. It’s hard ENOUGH to figure out how Windows works, and how your hardware works, and to write a driver. NOW we introduce the variability of a random framework into the mix?
It increasingly seems to me that what (may be) good for the world of app world is not necessarily ALSO good for the kernel-mode world. Whether it’s agile, flighted features, or open source value add frameworks. I am rapidly coming to the conclusion that the world of infrastructure benefits from different rules.
Peter
OSR
@OSRDrivers