add some macros for making request handlers easier:
* REQUEST_HEAD_STRUCT() declares a struct and checks size (assuming
length field already had been swapped)
* REQUEST_FIELD_CARD16() swaps a CARD16 (word) if neccessary
* REQUEST_FIELD_CARD32() swaps a CARD32 (dword) if neccessary
How to use them:
1. move swapping of lengths field into the SProc*Dispatch() and drop it
from the individual SProc*()'s
2. put REQUEST_HEAD_STRUCT() ontop of each Proc*()
3. add REQUEST_FIELD_*() below, for all fields to be swapped and
drop their swapping from the SProc*()'s
4. clean up unnecessary wrappers (SProc*()'s just be just call the
corresponding Proc*() by now)
5. let demux SProc just swap length field and call the normal Proc*Dispatch()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify writing reply payload into just one block.
This also makes further simplifications by subsequent patches easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply buffer in SELinuxSendItemsToClient() by putting it on stack.
No need to go through heap and free it later, if the compiler can do all
the work for us.
This also allows further generalizations of reply sending code by upcoming
commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some test cases are recycling the ClientRec between swapped/unwapped runs.
Make sure the Client's swapped flag is always reset in those cases.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Small buffers easily fit on stack, which is much faster (just moving SP),
and alloca()'ed buffers are cleaned up automatically on function leave,
no extra free() needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to read by using initialization of the reply
structs, at the point of declaration. Most of them aren't written to later,
just passed into WriteReplyToClient(). Also dropping some useless zero
assignments (struct initializers automatically zero-out unmentioned fields).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The original intention was negotiating versions before any further requests
can be processed, so requests that might become incompatible in future versions
still can be dispatched correctly. But practically that's never been the case:
there's just one major version, and it's unlikely that a new *major* version
(that might be incompatible with the current one, using same request codes for
different things) will come in the forseeable future.
So this extra logic isn't practically needed and just complicates dispatching.
Dropping it clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The diffenciation between Xinerama and single screen version is by tweaking
call vectors unncessarily complicated: it the only reason why these are
needed in the first place. Finally, it's just about one function, so it's
much easier just branching off in ProcDamageCreate() in case of Xinerama
is enabled.
This also clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move extra complexity out of the dispatch functions, so they're
really just switch/case statements calling the actual handler procs.
Preparation for further steps.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary struct,
so we can send it as one block. This allows for further simplifications by
subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary struct,
so we can send it as one block. This allows for further simplifications by
subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The payload lengths is already known, so we can easily collect the data
in a stack buffer and only need one WriteToClient() operation.
This also clears the road for further simplification/unification of the
reply sending code, coming with follow-up commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify sending by collecting in a local scoped buffer, so only one
WriteToClient() call is needed. This also makes further simplifications
by upcoming patches easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The way it's currently done, indirectly via macros calling dedicated
functions, is unnecessarily complicated. Simply inline it, just like
(almost) all the other extensions are doing it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ProcVidModeGetAllModeLines() is a bit complicated, because reply structs
differ depending the active protocol version. In order to make it easier to
understand and allow further simplification of the request/reply marshalling
(see ticket #1701), splitting the two protocol versions into separate functions.
Also collecting the whole payload in a stack buffer (size is already known
anyways), in order to save arbirary number of individual WriteToClient() calls,
but send out the whole reply in one pass, which in turn allows further
simplifications in the sending path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult