[OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class

[Paul Eggleton]

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 <marex at denx.de>
> > > > Cc: Richard Purdie <richard.purdie at linuxfoundation.org>
> > > > Cc: Koen Kooi <koen at dominion.thruhere.net>
> > > > Cc: Paul Eggleton <paul.eggleton at linux.intel.com>
> > > > Cc: Ross Burton <ross.burton at intel.com>
> > > > Cc: Bruce Ashfield <bruce.ashfield at windriver.com>
> > > > ---
> > > > 
> > > >   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 <empty here>". 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-<type> and just insist that a class for every image type 
exists. Ugly and kernel-*.bbclass already exists.

3) Try to search for a kernel-<type> 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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre