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

Richard Purdie richard.purdie at linuxfoundation.org
Mon Sep 16 15:32:14 UTC 2013


On Mon, 2013-09-16 at 14:33 +0100, Alex DAMIAN wrote:
> From: Alexandru DAMIAN <alexandru.damian at 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 at 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



--- 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):








More information about the bitbake-devel mailing list