[OE-core] [PATCH V2 6/7] controllers/masterimage.py: Make testimage kernel naming pattern universal

[Stoicescu, CorneliuX]

> -----Original Message-----
> From: Stefan Stanacar [mailto:sstncr at gmail.com]
> Sent: Saturday, June 07, 2014 3:39 PM
> To: Stoicescu, CorneliuX
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V2 6/7] controllers/masterimage.py: Make
> testimage kernel naming pattern universal
> 
> On Sat, Jun 7, 2014 at 1:54 PM, Stefan Stanacar <sstncr at gmail.com> wrote:
> >
> > On Jun 6, 2014 8:11 PM, "Corneliu Stoicescu"
> > <corneliux.stoicescu at intel.com>
> > wrote:
> >>
> >> YB: #6254
> >>
> >> The QemuTargetControl class does not specify any kernel naming but
> >> the runqemu script it uses uses the " KERNEL_IMAGETYPE + MACHINE +
> '.bin' "
> >> naming scheme.
> >> Modifying the other major target controller class,
> >> MasterImageHardwareTarget, to use the same kernel naming scheme.
> >>
> >
> > You can't do that because not all targets (bbb, nuc, etc) use a bin
> > kernel...
> >
> Ah, misunderstood... right, there is .bin link too
> 
> >> This is usefull also to outside scripts that want to anticipate the
> >> kernel file name for all target controllers.
> >
> > And what's wrong with the link? Bitbake will always take care of that
> > and point to the real file why can't the script dereference that?
> >

The link would be fine but:
- the link is not unique, there are at 2.
- the link used by testimage(without this patch) is not always the same. The script can create a link from one to the other but that is not necessary when we can have one name format for all target controllers to use. Also having the setup without links simplifies the setup of the images on the script side. 
- using the current kernel name for machines that use the same KERNEL_IMAGETYPE would override the kernel of the previous machine during the same test cycle. This could introduce complications, especially if we decide in the future to create a common download directories for multiple script instances.

I believe this is not a big change but introduces some simplification setup wise. I see no advantage leaving it as is aside avoiding making changes.

Regards,
Corneliu 

> > Cheers,
> > Stefan
> >
> >>
> >> Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu at intel.com>
> >> ---
> >>  meta/lib/oeqa/controllers/masterimage.py | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/lib/oeqa/controllers/masterimage.py
> >> b/meta/lib/oeqa/controllers/masterimage.py
> >> index b03c5bf..311f0cf 100644
> >> --- a/meta/lib/oeqa/controllers/masterimage.py
> >> +++ b/meta/lib/oeqa/controllers/masterimage.py
> >> @@ -52,7 +52,7 @@ class
> >> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget):
> >>          # test rootfs + kernel
> >>          self.image_fstype = self.get_image_fstype(d)
> >>          self.rootfs = os.path.join(d.getVar("DEPLOY_DIR_IMAGE",
> >> True), d.getVar("IMAGE_LINK_NAME", True) + '.' + self.image_fstype)
> >> -        self.kernel = os.path.join(d.getVar("DEPLOY_DIR_IMAGE", True),
> >> d.getVar("KERNEL_IMAGETYPE"))
> >> +        self.kernel = os.path.join(d.getVar("DEPLOY_DIR_IMAGE",
> >> + True),
> >> d.getVar("KERNEL_IMAGETYPE") + '-' + d.getVar('MACHINE') + '.bin')
> >>          if not os.path.isfile(self.rootfs):
> >>              # we could've checked that IMAGE_FSTYPES contains tar.gz
> >> but the config for running testimage might not be
> >>              # the same as the config with which the image was build,
> >> ie
> >> --
> >> 1.8.3.2
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core at lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core