From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mail.openembedded.org (Postfix) with ESMTP id 3455F65D00 for ; Mon, 4 May 2015 21:41:51 +0000 (UTC) Received: from mail.nefkom.net (unknown [192.168.8.184]) by mail-out.m-online.net (Postfix) with ESMTP id 3lgd1T1CqTz3hkWP; Mon, 4 May 2015 23:41:48 +0200 (CEST) X-Auth-Info: zlsdisoybd2UnCH3QPTx+mQoGrDfJrNQzHuh1d324fE= Received: from chi.localnet (unknown [195.140.253.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-auth.mnet-online.de (Postfix) with ESMTPSA id 3lgd1R6fw9zvdWV; Mon, 4 May 2015 23:41:47 +0200 (CEST) From: Marek Vasut To: Bruce Ashfield Date: Mon, 4 May 2015 23:41:47 +0200 User-Agent: KMail/1.13.7 (Linux/3.14-2-amd64; KDE/4.13.1; x86_64; ; ) References: <1430239116-7671-1-git-send-email-marex@denx.de> <553FD526.2020708@windriver.com> <201504282316.17774.marex@denx.de> In-Reply-To: <201504282316.17774.marex@denx.de> MIME-Version: 1.0 Message-Id: <201505042341.47651.marex@denx.de> Cc: Paul Eggleton , Koen Kooi , openembedded-core@lists.openembedded.org 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: Mon, 04 May 2015 21:41:53 -0000 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ? Best regards, Marek Vasut