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.10]) by mail.openembedded.org (Postfix) with ESMTP id 2732760884 for ; Sun, 19 Oct 2014 22:31:16 +0000 (UTC) Received: from mail.nefkom.net (unknown [192.168.8.184]) by mail-out.m-online.net (Postfix) with ESMTP id 3jLbRR4TZcz3hjNg; Mon, 20 Oct 2014 00:31:15 +0200 (CEST) X-Auth-Info: +P+QOWNAdGoetnplVe/AhLogW1w3NVLQfoTrJHn6ds4= 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 3jLbRR1wQbzvdWR; Mon, 20 Oct 2014 00:31:15 +0200 (CEST) From: Marek Vasut To: Bruce Ashfield Date: Mon, 20 Oct 2014 00:29:22 +0200 User-Agent: KMail/1.13.7 (Linux/3.13-trunk-amd64; KDE/4.13.1; x86_64; ; ) References: <1413746147-7120-1-git-send-email-marex@denx.de> <1413746147-7120-5-git-send-email-marex@denx.de> In-Reply-To: MIME-Version: 1.0 Message-Id: <201410200029.22491.marex@denx.de> Cc: Paul Eggleton , Koen Kooi , Patches and discussions about the oe-core layer Subject: Re: [PATCH 4/7] 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: Sun, 19 Oct 2014 22:31:24 -0000 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Monday, October 20, 2014 at 12:08:57 AM, Bruce Ashfield wrote: > On Sun, Oct 19, 2014 at 3:15 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. > > The commit log doesn't tell us why. What's the benefit or functionality we > gain via the change ? Ah right. I will be recycling some of those functions later on in the fitImage support. Also, it was suggested to me that there should be a separate class for each image type -- that all the image types should not be in kernel.bbclass . Does that make sense please? Best regards, Marek Vasut