If I were Microsoft, I would have structured MDLs as a list of objects, each
being derived from a base class. The fields of that base class would be
invisible to the outside: opaque. The derived class would have the fields
the driver can use, and then, of course, the user could sublass it further
if need be. As it stands, however, the design is already C oriented,
therefore there isn’t that much one can do except to encapsulate it.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ilya Lifshits
Sent: Monday, December 08, 2003 12:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: how to ensure atomic code in a kernel mode driver
Alberto,
Take the MDL object as example and describe how can you make it better
with c++
And i mean make it better not replace IoAllocateMdl with new because there
is no
real advantage here. I’m not pretend to know c++, never write more than few
lines
in c++, but i read carefully all your holly war for last few years and i
never seen a
real life advantage in c++ side of war examples :). So here a real object,
implemented in
c, for my opinion clean object oriented one, just show me any advantage in
implementing
this object in c++.
Regards Ilya.
At 10:27 AM 8/12/2003 -0500, you wrote:
Let me give you guys a few suggestions.
You call it Driver “object”, no ? Device “object” ? Make it so ! Real
objects, I mean. Make the driver stack an object too, make the Irp have a
member function that returns a reference to the stack. Remove all need to
pass Driver Object or Device Object as a parameter by using the kinds of
techniques employed by MFC to make templates out of documents and views.
Bury memory allocation inside the objects, so that we never have to invoke
any allocator function directly and we never have to worry about which pool
we getting data from: if an object requires the nonpaged pool, for example,
that should be buried inside the object itself through overriding the “new”
operator. Make partially opaque data structures into objects and use
attributes such as “private” and “protected” to hide what you don’t want
the
rest of the world to see. Use inheritance to derive Irp objects from other
Irp objects. Define all interfaces as abstract classes, COM style. Define
objects for all relevant hardware entities: buses, bridges, dma, agp,
processor, you name it, and make those objects behave like OS monitors,
multiprocessor safe: the serialization is inherent to the object and needs
not be negotiated by the programmer, it comes automatically. Give us a
coherent interface into the runtime, like for example what we have in STL.
Give us polymorphic versions of the API functions, so that we can omit
unnecessary parameters from the function calls and thus reduce the
possibility of error.
This and other things, would make writing drives a breeze.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Friday, December 05, 2003 6:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: how to ensure atomic code in a kernel mode driver
Since this relates to code I was directly (and indirectly) responsible
for I feel compelled to say that C++ would have been of little help
here.
I guess we might have written an allocator class for certain structures
that could keep some back-pocket resources to ensure we can make
progress on one i/o request at a time. Instead we wrote a set of
functions to do it. Doing it with the class keyword would have added
little.
Overriding operator-new so we didn’t define new allocator functions
would also provide little - either we pass in enough new data at each
invocation of operator-new to tell it to follow the work-in-low-memory
semantics, or we check the value when operator-new comes back and do
something special. Encapsulating it in a set of functions was just as
good as operator-new. And if you stick to a good function naming scheme
you can get most of the benefits of methods anyway.
OOP design paradigms are what are valuable here. If using an “OOP”
language without the associated OOP paradigms is not helpful, then
perhaps it’s not the language that’s providing the benefits.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
Sent: Friday, December 05, 2003 1:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: how to ensure atomic code in a kernel mode driver
…
>Given the amount of labour MS did to the disk stack on XP (NO resources
>are allocated in critical IO paths) - I can hardly imagine C++ to be
>suitable
for
>such a task.
Let me put it this way: doing the XP stack in C++ would entail a lot
less work.
…
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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@jungo.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@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.