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

[Marek Vasut]

On Wednesday, May 13, 2015 at 12:27:50 AM, Paul Eggleton wrote:
> 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.

OKi, I will implement this and repost the series.

Thanks!

Best regards,
Marek Vasut