From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id 6DDCC73D16 for ; Tue, 12 May 2015 15:38:21 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.9/8.14.9) with ESMTP id t4CFcF9p027617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 08:38:16 -0700 (PDT) Received: from [128.224.56.48] (128.224.56.48) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.224.2; Tue, 12 May 2015 08:38:15 -0700 Message-ID: <55521E66.4090908@windriver.com> Date: Tue, 12 May 2015 11:38:14 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Eggleton , References: <1430239116-7671-1-git-send-email-marex@denx.de> <201504282316.17774.marex@denx.de> <201505042341.47651.marex@denx.de> <59645923.jaN1ZMuDDz@peggleto-mobl.ger.corp.intel.com> In-Reply-To: <59645923.jaN1ZMuDDz@peggleto-mobl.ger.corp.intel.com> Cc: Marek Vasut Subject: Re: [PATCH 4/8] kernel: Pull uImage generation into separate class 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: Tue, 12 May 2015 15:38:21 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 2015-05-12 10:15 AM, Paul Eggleton wrote: > On Monday 04 May 2015 23:41:47 Marek Vasut wrote: >> On Tuesday, April 28, 2015 at 11:16:17 PM, Marek Vasut wrote: >>> On Tuesday, April 28, 2015 at 08:44:54 PM, Bruce Ashfield wrote: >>>> On 2015-04-28 12:38 PM, Marek Vasut wrote: >>>>> Pull the uImage image format generation from kernel.bbclass into >>>>> a separate kernel-uimage.bbclass. The recipes which now need to >>>>> generate an uImage will have to inherit kernel-uimage instead of >>>>> kernel class. >>>>> >>>>> Signed-off-by: Marek Vasut >>>>> Cc: Richard Purdie >>>>> Cc: Koen Kooi >>>>> Cc: Paul Eggleton >>>>> Cc: Ross Burton >>>>> Cc: Bruce Ashfield >>>>> --- >>>>> >>>>> meta/classes/kernel-uimage.bbclass | 48 >>>>> +++++++++++++++++++++++++++++++++ meta/classes/kernel.bbclass >>>>> >>>>> | 55 +++++++------------------------------- 2 files changed, 58 >>>>> >>>>> insertions(+), 45 deletions(-) >>>>> create mode 100644 meta/classes/kernel-uimage.bbclass >>>>> >>>>> NOTE: The "inherit kernel-uimage" in kernel.bbclass should be changed >>>>> to >>>>> >>>>> something like "inherit kernel-${@d.getVar("KERNEL_IMAGETYPE", >>>>> True).lower()}" but the problem is that I only want to perform >>>>> the inheritance for uimage and fitimage, the other image types >>>>> don't need to inherit any additional special stuff. >>>>> Paul suggested I can do "inherit ". This would at >>>>> least let me implement a python function which returns either >>>>> "kernel-uimage", "kernel-fitimage" or "" and based on that, I >>>>> could inherit the particular image type specifics into >>>>> kernel.bbclass. >>>>> What I don't know how to implement well is this function which >>>>> returns those three strings based on the KERNEL_IMAGETYPE. What >>>>> I would like to avoid is encoding those strings explicitly into >>>>> the function, since that would force each new kernel image >>>>> format to also edit this function in kernel.bbclass . >>>>> Apparently, checking whether class exists and inheriting it >>>>> only if it does is also not a simple task. >>>> >>>> Agreed that this would be better. It would remove a lot of the checks >>>> in the other tasks for the image type. >>> >>> Hi! >>> >>> Yes, that's indeed true. All the image type checks would disappear from >>> kernel-uimage and kernel-fitimage bbclasses. >>> >>>> I'm not aware of the exact details on how to make this work, but >>>> hopefully others have the foo. >> >> Any ideas please ? > > To me this is about how we wish to structure these classes. That's not my > call, but to enumerate the options - unless I'm missing something we have to > choose between: > > 1) Hardcode uimage/fitimage. Hard to extend. > > 2) inherit kernel- and just insist that a class for every image type > exists. Ugly and kernel-*.bbclass already exists. > > 3) Try to search for a kernel- class and inherit it if one is found. > AFAIK we don't do this kind of thing anywhere else so this doesn't seem right > to me. > > 4) Establish some other mechanism for registering kernel image type classes > (KERNEL_CLASSES ?). Not sure if we want to do this but it is at least a common > mechanism elsewhere in the system. I wasn't familiar with an option like this, but if we can do something for the kernel classes that follows the existing patterns .. it makes a lot of sense. I really don't want to invent something new here either. So something along the lines of the way that image.bbclass works with the IMAGE_CLASSES ? Bruce > > Cheers, > Paul >