On Sat, Dec 20, 2014 at 12:27:08PM -0800, Jamey Sharp wrote: > We've talked about doing the xserver equivalent of XCB for years--that is, > auto-generating the protocol serialization and deserialization code from > XCB's machine-readable descriptions of the X protocol and extensions. > > Considering the recent CVEs in that code, I think it's time. So I want to > collect folks' thoughts on what server-side XCB should look like. > > At a high level, which code should we be generating? Off the top of my > head, I'm thinking the dispatch tables and all the swap procedures, as a > first target in order to get the codegen infrastructure merged and tested. > Then it'd be nice to generate code that validates arguments and returns > appropriate errors. Thoughts?
XCB's client code turns a function call with arguments into data on the wire. I think the XCB server code should turn data on the wire into a dispatched function call, with approximately the same arguments and types as the original XCB client function. That same server code can then call an XCB reply-generation function, which will pack reply data onto the wire. (Bonus if you can then trivially substitute a different transport/RPC layer, or write an X protocol proxy that passes through to another X server.) We've talked several times about modifying XCB's client layer to make it easier to construct requests more incrementally, particularly for complex nested structs/arrays, to avoid having to hand-construct a complex data structure before calling XCB. (APIs like protobuf-c might provide some useful inspiration for incremental construction of nested data structures.) I think the server has more calls that would require such an incremental API, so designing that in from the start seems preferable, rather than adding it after first constructing an all-data-at-once API. - Josh Triplett _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
