[bitbake-devel] [PATCH 28/30] command: add CommandStarted event

Richard Purdie richard.purdie at linuxfoundation.org
Mon Dec 7 17:36:57 UTC 2015


Hi Ed,

On Wed, 2015-12-02 at 10:03 -0800, brian avery wrote:
> From: Ed Bartosh <ed.bartosh at linux.intel.com>
> 
> This event will be used by toasterui to set BRBE build parameter
> as soon as it's provided to bitbake server by Toaster.
> 
> Signed-off-by: Ed Bartosh <ed.bartosh at linux.intel.com>
> Signed-off-by: brian avery <avery.brian at gmail.com>
> ---
>  lib/bb/command.py | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/lib/bb/command.py b/lib/bb/command.py
> index 74106d1..78ce03a 100644
> --- a/lib/bb/command.py
> +++ b/lib/bb/command.py
> @@ -31,6 +31,11 @@ Commands are queued in a CommandQueue
>  import bb.event
>  import bb.cooker
>  
> +class CommandStarted(bb.event.Event):
> +    def  __init__(self, commandline):
> +        bb.event.Event.__init__(self)
> +        self.commandline = commandline
> +
>  class CommandCompleted(bb.event.Event):
>      pass
>  
> @@ -60,6 +65,7 @@ class Command:
>          self.currentAsyncCommand = None
>  
>      def runCommand(self, commandline, ro_only = False):
> +        bb.event.fire(CommandStarted(commandline), self.cooker.expanded_data)
>          command = commandline.pop(0)
>          if hasattr(CommandsSync, command):
>              # Can run synchronous commands straight away

I'm not sure I like the idea of this, particularly after I've seen what
you're using it to do. Just from a performance standpoint, adding in an
event per command execution adds in round trips and will increase the
time something simple like "bitbake -p" takes to do nothing when the
cache is hot.

I note in a later patch you use this to check for a command coming from
elsewhere to modify the data store and I worry that we'll end up with
unstructured code if we encourage people to do that too.

I did briefly talk to Brian and he mentioned you needed a way to
differentiate between events from different builds. I'd suggest you can
could do this if you markup the events as they come through your event
receiver, since events for a specific build should come through a
specific socket. Worst case I'd prefer doing this internally to bitbake
rather than the command interception above but adding data to every
event being sent over IPC is something I'd prefer to avoid if we can
too.

Would you be able to see if there is a different way we could handle
this?

Cheers,

Richard






More information about the bitbake-devel mailing list