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

[Paul Eggleton]

On Wednesday 13 May 2015 00:18:07 Marek Vasut wrote:
> On Tuesday, May 12, 2015 at 10:57:11 PM, Paul Eggleton wrote:
> [...]
> 
> > > > > > 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.
> > > > > 
> > > > > 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 ?
> > > > 
> > > > Indeed, that's what I was referring to.
> > > 
> > > Doesn't that mean it would be possible for kernel.bbclass to inherit
> > > multiple classes -- for example kernel-uimage.bbclass and
> > > kernel-fitimage.bbclass -- at the same time ? Won't that make it
> > > impossible to remove the kernel type checks in kernel-uimage.bbclass ?
> > > But maybe having those checks in place is the right thing to do since
> > > there might be a target building both fitImage and uImage at the same
> > > time?
> > 
> > You will still need these checks, yes. To be honest I don't consider
> > having
> > those to be a bad thing though.
> 
> I am not very fond of such "blanket if", it certainly doesn't look very nice
> and it looks confusingly redundant especially if the image type
> implementation is in it's own dedicated class. But if you consider this OK,
> I will thus try and implement the KERNEL_IMAGE_CLASSES (that might be a
> better name) approach. OK ?

I think this is the best (or perhaps least worst) approach. KERNEL_CLASSES 
probably would be a better name - there's nothing inherently image type 
specific to this, we're just going to inherit its value.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre