Comment 11 for bug 1515558
Revision history for this message
| Alan Griffiths (alan-griffiths) wrote Re: [regression] Nested servers on mesa-kms select wrong (dummy) guest platform | #11 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
Having a (hopefully) temporary workaround that handles some common scenarios isn't a fix. Here (copied from the email discussion) are some notes about resolving this:
as discussed following today's standup the problems we face involves a number of issues beyond the probing logic.
There are three contexts that matter: The Host Server; The Nested Server; and, The Client.
At present these all resort to some form of "probing" to decide what platform module to load. This is wrong, but we've only recently started seeing the problems it causes. Only the Host Server should be making a decision on the platform, the Nested Server and the Client should respect that decision.
Currently, the client code sees no difference between KMS and X11 - it just chooses between "android" and "mesa", which is a decision that is usually right. However, if we ever get additional platforms that "look alike" it will encounter the same problems we've seen recently without needing a nested server. Consequently, it would be better for the server to tell it which driver to load.
The Nested Server is where we've seen problems arise. As it need not be running as the same user, with the same rights, with the same environment nor configuration options as the Host Server it cannot reliably deduce which platform the host has chosen. Consequently, it would be better for the Host Server to tell it which driver to load.
Also worth considering is that the Nested Server only needs a server platform module to instantiate a "GuestPlatform" the principle function of which is buffer allocation. With "New Buffer Semantics" this will be possible through the client API - which may obsolete the need for platform specific "GuestPlatform" implementations. If we can eliminate loading a platform module to create a "GuestPlatform" then we achieve a significant simplification.
Coming out of this there are several pieces of work:
1. improve the decision logic in the Host Server and platform probing to deal with tie-breaking. (E.g. KMS should be preferred to X11.)
2. Enable the server to inform the client/nested server of the correct platform module to load. (This doesn't need to be surfaced in the client API, it is internal.)
3. Once the NBS client API is finalized. Revisit the need for a platform specific GuestPlatform - ideally one can be written in terms of the client API.