Patchwork [bitbake-devel,2/7] bitbake: event: send the task dependency tree to UI

login
register
mail settings
Submitter Richard Purdie
Date Sept. 16, 2013, 3:32 p.m.
Message ID <1379345534.32201.14.camel@ted>
Download mbox | patch
Permalink /patch/58169/
State New
Headers show

Comments

Richard Purdie - Sept. 16, 2013, 3:32 p.m.
On Mon, 2013-09-16 at 14:33 +0100, Alex DAMIAN wrote:
> From: Alexandru DAMIAN <alexandru.damian@intel.com>
> 
> We add an event that will send the dependency tree
> graph to the UI client once it is computed.
> 
> This will allow the clients to display dependency
> data in an efficient manner, and not redo the runqueue
> computation specifically to get the dependency data.
> 
> Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
> ---
>  bitbake/lib/bb/cooker.py    | 3 +++
>  bitbake/lib/bb/runqueue.py  | 3 +++
>  bitbake/lib/bb/ui/knotty.py | 3 +++
>  3 files changed, 9 insertions(+)

I continue to feel quite strongly that this should only happen when
there are UIs connected that actually want this event. We actually have
two problems, this one and the part in bin/bitbake which says:

    # Collect all the caches we need
    if configParams.server_only:
        configuration.extra_caches = gather_extra_cache_data()
    else:
        configuration.extra_caches = getattr(ui_module, "extraCaches", [])

I was never happy when this went in and I've already had one complaint
about the memory resident bitbake server reparsing compared to the
normal knotty client. You asked how this could be fixed as you couldn't
see how it could be done. I have two ideas:

The first is simpler but only fixes this problem, not the caches one.
The basic idea there would be to query the event interface and see if
anyone was listening for DepTreeGenerated events. If nobody is, no point
in generating it.

The second idea was having "server features", the caches being a special
case of this. When UI clients connect, they would merge their features
into those of the server. I've shown some pseudo code below. The
"features" could take immediate effect, the caches requested would take
effect the next time the server reparses (i.e finish current command,
then they take effect). The server features would be sent to the server
via some special command which would be allowed in an otherwise readonly
server.

Does that help?

Cheers,

Richard

Patch

--- a/bitbake/bin/bitbake
+++ b/bitbake/bin/bitbake
@@ -327,6 +327,10 @@  def main():
             os.environ[k] = cleanedvars[k]
 
         try:
+            if configParams.remote_server:
+                # Request configuration.extra_caches
+                # Request server feature flags set in UI
+
             return ui_module.main(server_connection.connection, server_connection.events, configParams)
         finally:
             bb.event.ui_queue = []
diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
index 2c8d4dc..89bf7c6 100644
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -63,6 +63,20 @@  class CollectionError(bb.BBHandledException):
 class state:
     initial, parsing, running, shutdown, forceshutdown, stopped = range(6)
 
+#
+# Cooker Features control certain functionality in the server. This allows
+# things to happen only when we know we have a UI that needs the particular
+# feature. This is usually used to control event generation
+#
+class CookerFeatures(object):
+    def __init__(self):
+        self._features = ["generateRunQueueDepTreeEvents"]
+        for f in self._features:
+            setattr(self, f, False)
+    def merge(self, features):
+        for f in self._features:
+            v = getattr(features, f)
+            setattr(self, f, v)
 
 class SkippedPackage:
     def __init__(self, info = None, reason = None):