From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mail.openembedded.org (Postfix) with ESMTP id 995B665E11 for ; Sun, 17 Aug 2014 11:51:56 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so3234703lbd.22 for ; Sun, 17 Aug 2014 04:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l/2Tml5GBtME0C2sukxOTm7Sykf3MmNW6c7QdG7qBRE=; b=fDFeG0+2aPykyhuC82pM+v35v4RIoVWKHWKrpQcH04W+50yWqFeRrTLmlWMjgKoKMd gi9S91GMLUKa+D+vHJwe8SGNIzVxy7FTvr9+dNK4WtNs/AX/IFaHLn+91y7dXu90arzp /ctR+wkTbbj7ke9GieMtdNPx/F1NRp8QWqUF8bZBXv7Ew3349mCS3LlN3WjPpyRtZDhC Qw0wgPHv0hQGgD0Am9I9HXCxAp+vTogecCOT47LiY9Cv+GJtcbHCiaEL8buiwuwjfsf+ XbmTgSdZ4uPk6ASL3TIhb7x2HAyiFWaREkJI7pqGE0hgA56L1Gw0hAZlW0JQ7tHiqrZe /03Q== MIME-Version: 1.0 X-Received: by 10.152.5.66 with SMTP id q2mr23114757laq.11.1408276317816; Sun, 17 Aug 2014 04:51:57 -0700 (PDT) Received: by 10.112.26.210 with HTTP; Sun, 17 Aug 2014 04:51:57 -0700 (PDT) In-Reply-To: <1408265720.24858.6.camel@ted> References: <1406969694.6981.22.camel@ted> <1408265720.24858.6.camel@ted> Date: Sun, 17 Aug 2014 13:51:57 +0200 Message-ID: From: Jacob Kroon To: Richard Purdie Cc: openembedded-core Subject: Re: [PATCH RFC] pixbufcache: Use sceneQueueComplete event to simplify usage X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 11:51:58 -0000 Content-Type: multipart/alternative; boundary=089e0141a1ceab4c660500d1e12c --089e0141a1ceab4c660500d1e12c Content-Type: text/plain; charset=UTF-8 On Sun, Aug 17, 2014 at 10:55 AM, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Sun, 2014-08-17 at 10:33 +0200, Jacob Kroon wrote: > > On Sat, Aug 2, 2014 at 10:54 AM, Richard Purdie > > wrote: > > [This is an RFC which depends on a patch to bitbake to > > operate] > > > > Currently, we have a mess of dependencies for pixbufcache and > > even then > > it breaks since they might be controlled by PACKAGECONFIG. > > > > Instead, this patch proposes an alternative approach where we > > allow > > "fixups" from a sceneQueueComplete() event at the end of the > > setscene > > process. We signal the need for these using simply stamp > > files. > > > > The one downside is that the processing code needs to be in a > > global > > event handler like base.bbclass rather than > > pixbufcache.bbclass but this > > is probably a price worth paying to avoid the dependency mess? > > > > Signed-off-by: Richard Purdie > > > > > > > > > > Instead of having the sstate_postinst() touch "needpixbuf", could we > > make it write out the actual script that needs to be executed ? > > > > Then base.bbclass could iterate over any scripts installed by any > > sstate_postinst() and execute them. At least this would better isolate > > the pixbuf-code to pixbufcache.bbclass, and make the snippet in > > base.bbclass more generic. > > It does become trickier to avoid races when writing out that script. > Touching the file is rather easy from a lock perspective :) > > Ah.. right, I didn't think of that. Is there no framework already in place in bitbake/OE/Python that we could use for doing atomic write-out-file-if-it-doesn't-exist-yet ? --089e0141a1ceab4c660500d1e12c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 17, 2014 at 10:55 AM, Richard Purdie <richard.pu= rdie@linuxfoundation.org> wrote:
On S= un, 2014-08-17 at 10:33 +0200, Jacob Kroon wrote:
> On Sat, Aug 2, 2014 at 10:54 AM, Richard Purdie
> <richard.purd= ie@linuxfoundation.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[This is an RFC which depends on a pa= tch to bitbake to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operate]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Currently, we have a mess of dependen= cies for pixbufcache and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even then
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it breaks since they might be control= led by PACKAGECONFIG.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Instead, this patch proposes an alter= native approach where we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"fixups" from a sceneQueueC= omplete() event at the end of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0setscene
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0process. We signal the need for these= using simply stamp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0files.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The one downside is that the processi= ng code needs to be in a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0global
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0event handler like base.bbclass rathe= r than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pixbufcache.bbclass but this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is probably a price worth paying to a= void the dependency mess?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Signed-off-by: Richard Purdie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<richard.purdie@linuxfoundation.org>
>
>
>
> Instead of having the sstate_postinst() touch "needpixbuf", = could we
> make it write out the actual script that needs to be executed ?
>
> Then base.bbclass could iterate over any scripts installed by any
> sstate_postinst() and execute them. At least this would better isolate=
> the pixbuf-code to pixbufcache.bbclass, and make the snippet in
> base.bbclass more generic.

It does become trickier to avoid races when writing out that sc= ript.
Touching the file is rather easy from a lock perspective :)


Ah.. right, I didn't think of that. Is there= no framework already in place in bitbake/OE/Python that we could use for d= oing atomic write-out-file-if-it-doesn't-exist-yet ?
--089e0141a1ceab4c660500d1e12c--