RE: [NTDEV] Queue Management ...

The thing is it’s too late now. The majority of us have to write
drivers with backwards compatabillity which essentially means we would
either need to maintain two sets of binaries or atleast runtime
conditionallity on version number. As Gary points out, many have
already made these functions, and if they havn’t they’ll have to
anyway as a consequence of having to support older windows versions.
Speaking for myself I would hate to give up tested and proven code to
give way to new functions. Using new functions is often just not a
matter changing a #define but often requires rewritting of code in a
way that could potentially introduce new bugs. Where there ever a real
need for this kind of functions? Yes, indeed. It should’ve been there
in NT1.0 DDK.

Regards,
Anders

GL> Michal,

GL> What I was hoping was to get a dialog started that might show a need for
GL> such functionality. However, with only two of us “discussing” it, I ain’t a
GL> gonna hold my breath waiting for it to be added to the DDK. :slight_smile:

GL> I’m sure most of the “old timers” like you and I simply write such
GL> functionality and keep it in a tool box we use for projects we work on.

GL> Gary G. Little
GL> Staff Engineer
GL> Broadband Storage, Inc.
GL> xxxxx@broadstor.com

GL> -----Original Message-----
GL> From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
GL> Sent: Monday, July 16, 2001 10:39 AM
GL> To: NT Developers Interest List
GL> Subject: [ntdev] RE: [NTDEV] Queue Management …

GL> Gary,

GL> this is what I’m complaining about. Somebody “wise” makes rules how
GL> something should be used from his narrow point of view and ignores all other
GL> possibilities. Also ignores future evolution as you showed. The question
GL> isn’t “why?” but “why not?”. Double linked lists can be used for linking any
GL> structures and random access is of course necessary. Limit them for
GL> (advanced) FIFOs only and force developers to write own list management is
GL> IMHO stupid. This API is apparently incomplete and I don’t understand the
GL> developer which can make something like this. Because of these “wise”
GL> persons who know better what we need only 10% of kernel and native APIs is
GL> documented, some native functions exported by NTDLL aren’t exported by
GL> kernel and so on.

GL> Well, stop complaining. This one is easy to fix although I fully agree with
GL> you it would be nice to have it in HAL. Hopefully you explained them why
GL> pushfd / cli / popfd is necessary there :wink:

GL> Best regards,

GL> Michal Vodicka
GL> Veridicom
GL> (RKK - Skytale)
GL> [WWW: http://www.veridicom.com , http://www.skytale.com]

> ----------
> From: Gary G. Little[SMTP:xxxxx@inland.net]
> Reply To: NT Developers Interest List
> Sent: Sunday, July 15, 2001 7:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: [NTDEV] Queue Management …
>
> Michael,
>
> Actually in the conversations that I have had off line with the folks at
> Microsoft about this, I can understand why this function was omitted. No
> one
> thought they needed it since the general thinking was that the functions
> provided full filled the perceived need as to how this “queuing” would be
> used. If you have the view that these functions are, or will be used, only
> as FIFO’s into a piece of hardware, then you do not need to give the
> capability of unplugging an item from the middle of a queue and the
> hanging
> it on the hardware. Indeed, on the hardware end of things, I have bent
> over
> backwards to kiss my gluteus maximus to make sure that everything
> funneling
> into the hardware was first in first out. Why? Because if the user comes
> back to me and says “I got these out of order …” I can then say, “Ok,
> then
> why did you send them out order?”
>
> That, however, was in the beginning … today, we have device stacks and
> nodes all over the place, with possibly several drivers blessing a queue
> before it gets plugged into the PDO for transfer to the hardware, and it
> is
> quite possible that one of those drivers will need to POP an item from the
> middle of that queue. In other words, when the queue is going to a framis,
> then I need to open the framis aperture, but if I’m going to a widget,
> then
> a widget doesn’t have an aperture and I’ll only confuse the widget if I
> give
> it that item. Sure, the PDO can say “Widget or framis?”, but that adds
> complexity that can more easily be handled in an upper layer.
>
> In other words, the need for ExInterlockedRemoveEntryList has evolved.
> Those
> of us that need it, write it. It would, however, be nice if it were added
> to
> the HAL, so that it could be used across all possible hardware platforms.
>
> Gary
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Friday, July 13, 2001 6:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: [NTDEV] Queue Management …
>
> > ----------
> > From: Eliyas Yakub[SMTP:xxxxx@microsoft.com]
> > Reply To: NT Developers Interest List
> > Sent: Monday, July 09, 2001 7:44 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: [NTDEV] Queue Management …
> >
> > >“Gary G. Little” wrote in message:
>> >
>> > >Why has there never been an ExInterlockedRemoveEntryList to permit an
>> > >orthagonal, and atomic, management of doubly linked queues?
>> >
>> > The question boils down to, where did you get the pointer to the object
>> > you
>> > want to remove? If you had to traverse the list to find it then you
>> > already had to have the list locked in which case, when you find it you
>> > can
>> > just use RemoveEntryList. You can certainly come up with cases of
>> > having
>> > an arbitrary pointer to an object but the normal case is you had to get
>> > that
>> > pointer from somewhere. Anyway, that’s why.
>> >
>> Well, this is the way of thinking typical for DDKs :frowning: Somebody at
>> Microsoft makes the decision which is sufficient for DDK examples but bad
>> for the real world. The results are incomplete headers, documentation and
>> API as in this case. Yes, I also missed ExInterlockedRemoveEntryList and
>> implemented it myself.
>>
>> Best regards,
>>
>> Michal Vodicka
>> Veridicom
>> (RKK - Skytale)
>> [WWW: http://www.veridicom.com , http://www.skytale.com]
>>
>>
>>
>>
>>
>>
>> —
>> You are currently subscribed to ntdev as: xxxxx@inland.net
>> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>>
>> —
>> You are currently subscribed to ntdev as: xxxxx@rkk.cz
>> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>

GL> —
GL> You are currently subscribed to ntdev as: xxxxx@broadstor.com
GL> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

GL> —
GL> You are currently subscribed to ntdev as: xxxxx@flaffer.com
GL> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


Best regards,
Anders mailto:xxxxx@flaffer.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com