Why not use explicit spinlock acquisition for list operations instead of
ExInterlockedxxx?
----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Monday, July 16, 2001 10:46 PM
Subject: [ntdev] RE: [NTDEV] Queue Management …
> Michal,
>
> What I was hoping was to get a dialog started that might show a need for
> such functionality. However, with only two of us “discussing” it, I ain’t
a
> gonna hold my breath waiting for it to be added to the DDK. 
>
> I’m sure most of the “old timers” like you and I simply write such
> functionality and keep it in a tool box we use for projects we work on.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
> Sent: Monday, July 16, 2001 10:39 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: [NTDEV] Queue Management …
>
> Gary,
>
> this is what I’m complaining about. Somebody “wise” makes rules how
> something should be used from his narrow point of view and ignores all
other
> possibilities. Also ignores future evolution as you showed. The question
> isn’t “why?” but “why not?”. Double linked lists can be used for linking
any
> structures and random access is of course necessary. Limit them for
> (advanced) FIFOs only and force developers to write own list management is
> IMHO stupid. This API is apparently incomplete and I don’t understand the
> developer which can make something like this. Because of these “wise”
> persons who know better what we need only 10% of kernel and native APIs is
> documented, some native functions exported by NTDLL aren’t exported by
> kernel and so on.
>
> Well, stop complaining. This one is easy to fix although I fully agree
with
> you it would be nice to have it in HAL. Hopefully you explained them why
> pushfd / cli / popfd is necessary there 
>
> Best regards,
>
> Michal Vodicka
> Veridicom
> (RKK - Skytale)
> [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 
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
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.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