Xserver-spec: Delete DBE Idioms section

The code has been gone for a while

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This commit is contained in:
Alan Coopersmith 2010-11-27 10:46:44 -08:00 committed by Keith Packard
parent f4ba75a494
commit 903e0f6f0f

View File

@ -1361,70 +1361,6 @@ The sample server implementation for these routines
is in Xserver/os/util.c. is in Xserver/os/util.c.
</para> </para>
</section> </section>
<section>
<title>Idiom Support</title>
<para>
The DBE specification introduces the notion of idioms, which are
groups of X requests which can be executed more efficiently when taken
as a whole compared to being performed individually and sequentially.
This following server internal support to allows DBE
implementations, as well as other parts of the server,
to do idiom processing.
</para>
<para>
<blockquote><programlisting>
xReqPtr PeekNextRequest(xReqPtr req, ClientPtr client, Bool readmore)
</programlisting></blockquote>
If req is NULL, the return value will be a pointer to the start of the
complete request that follows the one currently being executed for the
client. If req is not NULL, the function assumes that req is a
pointer to a request in the client's request buffer, and the return
value will be a pointer to the the start of the complete request that
follows req. If the complete request is not available, the function
returns NULL; pointers to partial requests will never be returned. If
(and only if) readmore is TRUE, PeekNextRequest should try to read an
additional request from the client if one is not already available in
the client's request buffer. If PeekNextRequest reads more data into
the request buffer, it should not move or change the existing data.
</para>
<para>
<blockquote><programlisting>
void SkipRequests(xReqPtr req, ClientPtr client, int numskipped)
</programlisting></blockquote>
The requests for the client up to and including the one specified by
req will be skipped. numskipped must be the number of requests being
skipped. Normal request processing will resume with the request that
follows req. The caller must not have modified the contents of the
request buffer in any way (e.g., by doing byte swapping in place).
</para>
<para>
Additionally, two macros in os.h operate on the xReq
pointer returned by PeekNextRequest:
<blockquote><programlisting>
int ReqLen(xReqPtr req, ClientPtr client)
</programlisting></blockquote>
The value of ReqLen is the request length in bytes of the given xReq.
<blockquote><programlisting>
otherReqTypePtr CastxReq(xReq *req, otherReqTypePtr)
</programlisting></blockquote>
The value of CastxReq is the conversion of the given request pointer
to an otherReqTypePtr (which should be a pointer to a protocol
structure type). Only those fields which come after the length field
of otherReqType may be accessed via the returned pointer.
</para>
<para>
Thus the first two fields of a request, reqType and data, can be
accessed directly using the xReq * returned by PeekNextRequest. The
next field, the length, can be accessed with ReqLen. Fields beyond
that can be accessed with CastxReq. This complexity was necessary
because of the reencoding of core protocol that can happen due to the
BigRequests extension.
</para>
</section>
</section> </section>
<section> <section>