Absolutely unnecessary comlplexity.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 08, 2003 10:04 PM
Subject: [ntdev] RE: how to ensure atomic code in a kernel mode drive r
> 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.
>
>
> —
> 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