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

[Marek Vasut]

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 ?

Best regards,
Marek Vasut