RFC: server-side XCB

Sun Dec 21 09:00:19 PST 2014

Hi Jamey,

Thank you for your positive feedback.
and that you are willing to help and be involved.

On 12/21/14 15:49, Jamey Sharp wrote:
> That's great! If Asalle and Jaya don't mind, I'd like to be CC'd on
> progress reports and questions on these projects. I may be able to
> help.
Thank you for that offer.

That is, you like to become an informal co-mentor for these projects?
This may help as they'll get answers faster, and you may help
to catch things early that I may overlook.
(and you may reduce mentoring work for me.)

I hope we have approximately the same wavelength,
so that Asalle and Jaya get sufficiently consistent answers from both of us. :-)

In any case, we'll need to discuss critical design decisions publicly on xorg-devel,
as these should not be kept in private project communication for too long.
(Of course, we should get the ideas to some maturity internally in order to avoid
cluttering he xorg-devel list with trivial stuff. )

I'll wait for Jaya's and Asalle's feedback regarding that.

If they agree I'll first send you some info so you'll be up-to-speed
about the current state.

>
> The length-checking/byte-swapping proposal sounds like what I had in
> mind, and what Keith expressed interest in. I have some confusion
> about some of the details, 
I think the confusion is just from my way of describing this,
not from the technical stuff per se.

If you have any questions regarding the proposal, just tell me,
and I'll be glad to answer them. We probably should do this
on the xorg-devel list because:
Any stuff my proposal that is causing confusion for you,
is probably doing so for others, too.
> but I don't think they matter at this
> stage; 
Yep.
Now it's about the big picture stuff, so the project can get started.
We'll see how the details do when actual code is written.

> since we're talking about code generation, they'll be easy to
> change later if necessary.
Yep.
Only the integration with manually written code is hard to
change later.

Some advanced stuff of the code generator will also be
difficult to change later, so we should iron out any issues
soon for the generator, too.
In any case, we'll start with a simple X-Extension first.
We can use that to stabilize the general design
and integration.
So that the sophisticated stuff can then be implemented on
a stable basis.

Advanced stuff in the generator are things like parametrized
structs, sumof of expressions, etc, that I had to add to the
XCB XML description capabilities to support the XInput extension.

>
> The task you've labeled server-side XCB is fairly ambitious, I think.
> Sounds like that's roughly what Josh wants, details aside, and I was
> going to complain about ambition at him too. :-) If Jaya is going to
> do that, I think we should arrange an X.Org Extended Vacation of Code
> grant for her.
This will definitely be good.
How can we arrange an EVoC grant for her?
What steps do we need to take etc?

>
> Thanks for taking on mentorship of these tasks! Let me know how I can help.
Thank you for offering to help.
I'll let you know when we need help.

In particular we'll need help with timely reviewing
of patches and design proposals, so that the
projects will not get stalled for too long
due to waiting for reviews or feedback.
Especially to avoid that lots of code will have to be refactored
due to relevant feedback that's provided too late.

Asalle is working full time on that, and her OPW internship
has a fixed end. After that she may or may not contribute
on a volunteer bases. But she'll not be able to work full time
on it after the end of her internship. So each day delay due to
delayed reviewing is a day lost.

Jaya can work 50% of fulltime, and possibly more than that.
So that applies in a similar way to her, too.

We have built in some parallelism in the project plan,
so that they can work for a while, while prior stuff is reviewed.
But this has limits.

Chris
> Jamey
>
> On Sun, Dec 21, 2014 at 12:36 AM, Christian Linhart
> <chris at demorecorder.com> wrote:
>> There is already a project underway to do this.
>>
>> We would have sent the technical proposal in a few days.
>> I will send the technical proposal as an extra message, soon.
>>
>> In any case we should avoid that two teams are working on that independently.
>>
>> We have two interns at Xorg who are working on this under my mentorship:
>> * Asalle works as intern under the OPW-program ( http://www.x.org/wiki/XorgOPW/ )
>>   She will do the length checking and byte swapping.
>>
>> * Jaya is an intern without any formal program behind it.
>>   She will implement server-side XCB in requests, replys etc,
>>   i.e. will replace the usage of the manually written proto-headers
>>   with using XCB.
>>
>> Currently, both are setting up their work environment and getting acquainted with the code.
>> Both already have gained some experience with XCB during their qualification task etc.
>>
>> Me, I have 17 years experience with the X-Server source-code, especially with protocol handling,
>> from work in a commercial project.
>>
>> I have recently volunteered to become the maintainer of the XCB project.
>>
>> And I do understand the code of the XCB codegenerator. ;-)
>> I have already made several changes to it, and more are in the pipeline.
>>
>> I also have made lots of changes of the XCB protocol definition of XInput, with the goal of 100% coverage.
>> I will also complete the protocol definitions of the XInput and XKeyboard extensions'along with further changes in the XCB code generator.
>> (actually already finished with this. Just need to prepare this for posting on the XCB list.)
>>
>> Cheers,
>>
>> Chris
>>
>>
>> On 12/20/14 21:27, 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 code generator is implemented in Python. Can we make the same choice in the xserver build process?
>>>
>>> Anything else I should be thinking about?
>>> Jamey
>>>
>>>
>>>
>>> _______________________________________________
>>> xorg-devel at lists.x.org: X.Org development
>>> Archives: http://lists.x.org/archives/xorg-devel
>>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel