[poky] [PATCH 0/4][Image Creator]Put extra requested fields into different cache files

[Ke, Liping]

Hi, Richard,

Thanks for your feedback!!! please see below answers.

criping

> These patches are good and I like the ultimate result but the patches
> themselves could use some tweaks in the order they make changes. Ideally
> changes need to be made in a way that each patch can stand on its own so
> I could apply patches 1 and 2, leave 3 and 4 out and the code should
> still work.
> 
> In this sense, the series should really be a set of patches which:
> 
> a) Adds "bitbake_mode" and allows UIs to define cache data
> b) Adds the cache data to hob
> c) Drops the cache data used only by hob from the core
Yes, in general I want to do the same thing. Each patch in the serial will
not break the current cs. Patch[1/4], patch[2/4]& patch [3/4] are for a) and b).
But for c), because of the implantation algorithm I adopted, it's merged with
extra cache data implementation (the biggest patch).

 
> I've also the following comments on the code in general:
> 
> a) Could we move the hob specific cache data from cache.py to hob.py. If
> not, I'd like to understand why not and maybe address those issues. My
> point is you shouldn't need to change cache.py to add extra cache data.

you mean that we will have a separate ExtraCache (I guess hob or adt-installer should have the similar logic?)
implementation file, which has similar functionality with cache.py? 
Oh, I did not think of this implementation at all when implement. In my mind, change less code is the principle since
this part of the code is the core of bitbake:)  If split, many codes in cache could be reused by both cache.py and hob.py?

And also, if you think it is a must, could we split the task, for this phase, keep it in the same file. 
And then refactory them in another patch later? Seems there're many tasks for image creator? Seems the schedule is
tight?

> b) Could we rename "bitbake_mode" to "extracaches" or something?
> "bitbake_mode" is a bit too generic and meaningless.
Sure. It's nice.

> c) I was also wondering how hard it would be to make this an array and
> allow more than one to be loaded? I'm thinking of the use case where we
> may have more than one "UI" in future and configure things so the user
> can switch between them without re-parsing.
> 
Hi, Richard, actually user could have more than one data file. If we have autobuilder extra requests,
we can easily extend with few codes: (just like patch 3)
1)define autobuilder_extra_fields,
2) declare autobuilder namedtuple class
3) add else in ExtraClassFactory for defining from_metadata.
Then the bb_cacheautobuilder.dat will be loaded and processed. 
Then there would be more than two cache data files (bb_cache.dat, bb_cachehob.dat, bb_cacheautobuilder.dat, etc).
But each time when bitbake is running, only two files will be loaded/saved. (bb_cache.dat, bb_cachehob.dat)
or (bb_cache.dat, bb_cacheautobuilder.dat). bitbake_mode are used for passing the parameters, 'hob' or 'autobuilder'?
Is this what you mean?

> Cheers,
> 
> Richard