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 DDKsSomebody 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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com