Skip to contentSkip to conversation

Put extra requested fields into different cache files

PATCH In review Liping Ke 2 participants 11 messages May 9, 2011 – May 12, 2011

lore
Share & tools
lore

Liping Ke

author
#0 lore raw

cover Put extra requested fields into different cache files

From: Liping Ke <[email protected]>

Below four patches are for putting extra requested fields inito different cache files instead of using only on bb_cache.dat. Now image creator need extra three fields. And in the future, there might be more similar requests. For each extra requestor, we will save the requested fields data into a separate cache files so that those who don't need it will not be impacted with larger fields and large data files.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/cache_impl
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lke/cache_impl

Thanks,
Liping Ke <[email protected]>
---

Liping Ke (4):
Introduce new param bitbake_mode into Cache.py Split Cache Data Retrieve method from Data Fields Introduce Extra required fields for image creator Implement independent cache for Extra Cache Fields Request

 bitbake/lib/bb/cache.py  |  189 +++++++++++++++++++++++++++++++++++++---------
 bitbake/lib/bb/cooker.py |   55 ++++++++++----
 2 files changed, 193 insertions(+), 51 deletions(-)
author
#1 lore raw

PATCH 1/4 Put extra requested fields into different cache files

From: Liping Ke <[email protected]>

This patch introduce new param bitbake_mode into Cache.py. When using ui mode, we will save ui_mode required extra cache fields into a separate cache file. This patch firstly introduce this bitbake_mode parameter. It will be used in the following patches.

---
 bitbake/lib/bb/cache.py  |   19 ++++++++++++++++---
 bitbake/lib/bb/cooker.py |   11 ++++++++---
 2 files changed, 24 insertions(+), 6 deletions(-)
bitbake/lib/bb/cache.py +16 -3
index d083c51..c86aa14 100644
@@ -187,7 +187,10 @@ class Cache(object):
     BitBake Cache implementation
     """
 
-    def __init__(self, data):
+    def __init__(self, data, bitbake_mode=None):       
+        # Pass bitbake_mode information into Cache constructor
+        # It will be used in later for deciding whether
+        # we need separate cache file dump/load support
         self.cachedir = bb.data.getVar("CACHE", data, True)
         self.clean = set()
         self.checked = set()
@@ -196,6 +199,11 @@ class Cache(object):
         self.data_fn = None
         self.cacheclean = True
 
+        # Below three variables are used for loading extra cache
+        self.extra_depends_cache = {}        
+        self.bitbake_mode = bitbake_mode
+        self.extra_cachefile = None
+
         if self.cachedir in [None, '']:
             self.has_cache = False
             logger.info("Not using a cache. "
@@ -205,6 +213,11 @@ class Cache(object):
         self.has_cache = True
         self.cachefile = os.path.join(self.cachedir, "bb_cache.dat")
 
+        # if bitbake_mode is not None, we need to load extra cache files
+        if self.bitbake_mode:
+            self.extra_cachefile = os.path.join(self.cachedir,
+                        "bb_extracache_%s.dat" %self.bitbake_mode)
+
         logger.debug(1, "Using cache in '%s'", self.cachedir)
         bb.utils.mkdirhier(self.cachedir)
 
@@ -302,7 +315,7 @@ class Cache(object):
         return bb_data[virtual]
 
     @classmethod
-    def parse(cls, filename, appends, configdata):
+    def parse(cls, filename, appends, configdata, bitbake_mode=None):
         """Parse the specified filename, returning the recipe information"""
         infos = []
         datastores = cls.load_bbfile(filename, appends, configdata)
@@ -565,7 +578,7 @@ class CacheData(object):
     The data structures we compile from the cached data
     """
 
-    def __init__(self):
+    def __init__(self, bitbake_mode):
         # Direct cache variables
         self.providers = defaultdict(list)
         self.rproviders = defaultdict(list)
bitbake/lib/bb/cooker.py +8 -3
index a1cd4d7..32ad96d 100644
@@ -71,6 +71,10 @@ class BBCooker:
             self.server = server.BitBakeServer(self)
 
         self.configuration = configuration
+        # Cooker can get the bitbake mode information from configuration,
+        # we need to log down this information and pass it to Cache for
+        # extra cache file implementation
+        self.bitbake_mode = configuration.ui
 
         self.configuration.data = bb.data.init()
 
@@ -713,9 +717,10 @@ class BBCooker:
 
         self.buildSetVars()
 
-        self.status = bb.cache.CacheData()
+        self.status = bb.cache.CacheData(self.bitbake_mode)
         infos = bb.cache.Cache.parse(fn, self.get_file_appends(fn), \
-                                     self.configuration.data)
+                                     self.configuration.data, \
+                                     self.bitbake_mode)
         infos = dict(infos)
 
         fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
@@ -859,7 +864,7 @@ class BBCooker:
                 else:
                     collectlog.info("You have disabled Psyco. This decreases performance.")
 
-            self.status = bb.cache.CacheData()
+            self.status = bb.cache.CacheData(self.bitbake_mode)
 
             ignore = bb.data.getVar("ASSUME_PROVIDED", self.configuration.data, 1) or ""
             self.status.ignored_dependencies = set(ignore.split())
Signature · 1 line
1.7.0.4
author
#2 lore raw

PATCH 2/4 Put extra requested fields into different cache files

In reply to Liping Ke

From: Liping Ke <[email protected]>

This patch splits Cache Data Retrieve method from Data Fields. Data Retrive methods will be reused by Extra Cache Data fields. It is independent Class methods for data retrieving.

---
 bitbake/lib/bb/cache.py |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
bitbake/lib/bb/cache.py +2 -1
index c86aa14..dec8bdd 100644
@@ -83,7 +83,7 @@ recipe_fields = (
 )
 
 
-class RecipeInfo(namedtuple('RecipeInfo', recipe_fields)):
+class RecipeRetrieve():
     __slots__ = ()
 
     @classmethod
@@ -117,6 +117,7 @@ class RecipeInfo(namedtuple('RecipeInfo', recipe_fields)):
     def getvar(cls, var, metadata):
         return metadata.getVar(var, True) or ''
 
+class RecipeInfo(namedtuple('RecipeInfo', recipe_fields), RecipeRetrieve):
     @classmethod
     def make_optional(cls, default=None, **kwargs):
         """Construct the namedtuple from the specified keyword arguments,
Signature · 1 line
1.7.0.4
author
#3 lore raw

PATCH 3/4 Put extra requested fields into different cache files

In reply to Liping Ke

From: Liping Ke <[email protected]>

This patch introduces Extra required fields for image creator. We introduce extra required fields as well as namedtuple recipeinfo class here. We also define the data retrieving methods for this extra recipeinfo class. This factory methods can be easily extended for furthing expanding. The extended Hob(Image Creator) class will be used in the following patches.

---
 bitbake/lib/bb/cache.py |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)
bitbake/lib/bb/cache.py +29 -0
index dec8bdd..dc112ff 100644
@@ -117,7 +117,36 @@ class RecipeRetrieve():
     def getvar(cls, var, metadata):
         return metadata.getVar(var, True) or ''
 
+# This three fields are only requested by Image Creator
+# hob_recipe_fields, HobRecipeInfo Definition are both
+# introduced by Image Creator. If a user want to introduce
+# more fields, we need to to the same thing as below:
+# 1. introduce extra recipe fields
+# 2. Define your extra named tuple class
+# 3. Add extra data loading methods in the else part of
+#    the Factory Class.
+hob_extra_recipe_fields = (
+    'summary',
+    'license',
+    'section'
+)
+
+HobExtraRecipeInfo = namedtuple('HobExtraRecipeInfo', hob_extra_recipe_fields)
+    
+class ExtraRecipeInfoFactory(RecipeRetrieve):
+    @classmethod
+    def from_metadata(cls, bitbake_mode, metadata):
+        if bitbake_mode == "hob":
+            return HobExtraRecipeInfo(
+                summary          = cls.getvar('SUMMARY', metadata),
+                license          = cls.getvar('LICENSE', metadata),
+                section          = cls.getvar('SECTION', metadata),
+            )
+
+
 class RecipeInfo(namedtuple('RecipeInfo', recipe_fields), RecipeRetrieve):
+    # Please note: fields are the static class member
+    # in namedtuple class RecipeInfo
     @classmethod
     def make_optional(cls, default=None, **kwargs):
         """Construct the namedtuple from the specified keyword arguments,
Signature · 1 line
1.7.0.4
author
#4 lore raw

PATCH 4/4 Put extra requested fields into different cache files

In reply to Liping Ke

From: Liping Ke <[email protected]>

This patch implements independent cache for Extra Cache Fields Request Since Image Creator need extra cache fields which are not used by bitbake, we create the extra cache file to load this extra cache fields for making it more extensible. In the future, we can handle similar request. This implementation does not touch the base recipe info path. Extra fields are dealt with separately.

---
 bitbake/lib/bb/cache.py  |  138 +++++++++++++++++++++++++++++++++++----------
 bitbake/lib/bb/cooker.py |   44 ++++++++++----
 2 files changed, 138 insertions(+), 44 deletions(-)
bitbake/lib/bb/cache.py +107 -31
index dc112ff..aefd26b 100644
@@ -75,9 +75,6 @@ recipe_fields = (
     'basetaskhashes',
     'hashfilename',
     'inherits',
-    'summary',
-    'license',
-    'section',
     'fakerootenv',
     'fakerootdirs'
 )
@@ -204,9 +201,6 @@ class RecipeInfo(namedtuple('RecipeInfo', recipe_fields), RecipeRetrieve):
             rdepends_pkg     = cls.pkgvar('RDEPENDS', packages, metadata),
             rrecommends_pkg  = cls.pkgvar('RRECOMMENDS', packages, metadata),
             inherits         = cls.getvar('__inherit_cache', metadata),
-            summary          = cls.getvar('SUMMARY', metadata),
-            license          = cls.getvar('LICENSE', metadata),
-            section          = cls.getvar('SECTION', metadata),
             fakerootenv      = cls.getvar('FAKEROOTENV', metadata),
             fakerootdirs     = cls.getvar('FAKEROOTDIRS', metadata),
         )
@@ -259,11 +253,21 @@ class Cache(object):
         old_mtimes = [old_mtime for _, old_mtime in deps]
         old_mtimes.append(newest_mtime)
         newest_mtime = max(old_mtimes)
+        
+        # We need load extra cache
+        if bitbake_mode:
+            if bb.parse.cached_mtime_noerror(self.cachefile) >= newest_mtime \
+                    and bb.parse.cached_mtime_noerror(self.extra_cachefile) \
+                            >= newest_mtime:
+                self.load_cachefile()
+            elif os.path.isfile(self.cachefile):
+                logger.info("Out of date cache found, rebuilding...")
+        else:
+            if bb.parse.cached_mtime_noerror(self.cachefile) >= newest_mtime:
+                self.load_cachefile()
+            elif os.path.isfile(self.cachefile):
+                logger.info("Out of date cache found, rebuilding...") 
 
-        if bb.parse.cached_mtime_noerror(self.cachefile) >= newest_mtime:
-            self.load_cachefile()
-        elif os.path.isfile(self.cachefile):
-            logger.info("Out of date cache found, rebuilding...")
 
     def load_cachefile(self):
         with open(self.cachefile, "rb") as cachefile:
@@ -283,9 +287,36 @@ class Cache(object):
                 return
 
             cachesize = os.fstat(cachefile.fileno()).st_size
-            bb.event.fire(bb.event.CacheLoadStarted(cachesize), self.data)
 
             previous_percent = 0
+            current_progress = 0
+            extra_current_progress = 0
+
+            if self.bitbake_mode:
+                with open(self.extra_cachefile, "rb") as extra_cachefile:
+                    cachesize += os.fstat(extra_cachefile.fileno()).st_size
+                    pickled_extra = pickle.Unpickler(extra_cachefile)
+                    bb.event.fire(
+                            bb.event.CacheLoadStarted(cachesize), self.data)
+                    # Refresh Progress Bar                    
+                    while extra_cachefile:
+                        try:
+                            key = pickled_extra.load()
+                            value = pickled_extra.load()
+                        except Exception:
+                            break
+                        self.extra_depends_cache[key] = value
+                        current_progress = extra_cachefile.tell()
+                        current_percent = 100 * current_progress / cachesize
+                        if current_percent > previous_percent:
+                            previous_percent = current_percent
+                            bb.event.fire(
+                                bb.event.CacheLoadProgress(current_progress),
+                                          self.data)
+                extra_current_progress = current_progress
+            else:
+                bb.event.fire(bb.event.CacheLoadStarted(cachesize), self.data)
+
             while cachefile:
                 try:
                     key = pickled.load()
@@ -296,7 +327,7 @@ class Cache(object):
                 self.depends_cache[key] = value
 
                 # only fire events on even percentage boundaries
-                current_progress = cachefile.tell()
+                current_progress = cachefile.tell() + extra_current_progress
                 current_percent = 100 * current_progress / cachesize
                 if current_percent > previous_percent:
                     previous_percent = current_percent
@@ -304,8 +335,8 @@ class Cache(object):
                                   self.data)
 
             bb.event.fire(bb.event.CacheLoadCompleted(cachesize,
-                                                      len(self.depends_cache)),
-                          self.data)
+                    len(self.depends_cache) + len(self.extra_depends_cache)),
+                            self.data)
 
     @staticmethod
     def virtualfn2realfn(virtualfn):
@@ -348,6 +379,7 @@ class Cache(object):
     def parse(cls, filename, appends, configdata, bitbake_mode=None):
         """Parse the specified filename, returning the recipe information"""
         infos = []
+        extra_infos = []
         datastores = cls.load_bbfile(filename, appends, configdata)
         depends = set()
         for variant, data in sorted(datastores.iteritems(),
@@ -359,7 +391,11 @@ class Cache(object):
                 data.setVar("__depends", depends)
             info = RecipeInfo.from_metadata(filename, data)
             infos.append((virtualfn, info))
-        return infos
+            if bitbake_mode:
+                extra_info = \
+                    ExtraRecipeInfoFactory.from_metadata(bitbake_mode, data)
+                extra_infos.append((virtualfn, extra_info))
+        return infos, extra_infos
 
     def load(self, filename, appends, configdata):
         """Obtain the recipe information for the specified filename,
@@ -372,15 +408,20 @@ class Cache(object):
         cached = self.cacheValid(filename)
         if cached:
             infos = []
+            extra_infos= []
             info = self.depends_cache[filename]
-            for variant in info.variants:
+            for i in range(0, len(info.variants)):
+                variant = info.variants[i]
                 virtualfn = self.realfn2virtual(filename, variant)
                 infos.append((virtualfn, self.depends_cache[virtualfn]))
+                if self.bitbake_mode:
+                    extra_infos.append((virtualfn, \
+                            self.extra_depends_cache[virtualfn]))
         else:
             logger.debug(1, "Parsing %s", filename)
-            return self.parse(filename, appends, configdata)
+            return self.parse(filename, appends, configdata, self.bitbake_mode)
 
-        return cached, infos
+        return cached, infos, extra_infos
 
     def loadData(self, fn, appends, cfgData, cacheData):
         """Load the recipe info for the specified filename,
@@ -388,13 +429,17 @@ class Cache(object):
         the recipe information to the supplied CacheData instance."""
         skipped, virtuals = 0, 0
 
-        cached, infos = self.load(fn, appends, cfgData)
-        for virtualfn, info in infos:
+        cached, infos, extra_infos = self.load(fn, appends, cfgData)
+        for i in range (0, len(infos)):
+            (virtualfn, info) = infos[i]
+            if self.bitbake_mode:
+                extra_info = extra_infos[i]
             if info.skipped:
                 logger.debug(1, "Skipping %s", virtualfn)
                 skipped += 1
             else:
-                self.add_info(virtualfn, info, cacheData, not cached)
+                self.add_info(virtualfn, info, extra_info, \
+                            cacheData, not cached)
                 virtuals += 1
 
         return cached, skipped, virtuals
@@ -426,7 +471,8 @@ class Cache(object):
         self.checked.add(fn)
 
         # File isn't in depends_cache
-        if not fn in self.depends_cache:
+        if (not fn in self.depends_cache) or (self.bitbake_mode \
+                       and (not fn in self.extra_depends_cache)):
             logger.debug(2, "Cache: %s is not cached", fn)
             return False
 
@@ -467,7 +513,9 @@ class Cache(object):
         for cls in info.variants:
             virtualfn = self.realfn2virtual(fn, cls)
             self.clean.add(virtualfn)
-            if virtualfn not in self.depends_cache:
+            if (virtualfn not in self.depends_cache) or \
+                         (self.bitbake_mode \
+                         and virtualfn not in self.extra_depends_cache):
                 logger.debug(2, "Cache: %s is not cached", virtualfn)
                 invalid = True
 
@@ -494,6 +542,12 @@ class Cache(object):
         if fn in self.depends_cache:
             logger.debug(1, "Removing %s from cache", fn)
             del self.depends_cache[fn]
+        # when deleting, we need to maintain the consistency
+        # of the two independent cache
+        if self.bitbake_mode and fn in self.extra_depends_cache:
+            logger.debug(1, "Removing %s from ui_extra_cache", fn)
+            del self.extra_depends_cache[fn]
+
         if fn in self.clean:
             logger.debug(1, "Marking %s as unclean", fn)
             self.clean.remove(fn)
@@ -519,15 +573,26 @@ class Cache(object):
                 pickler.dump(key)
                 pickler.dump(value)
 
+        # Sync back the extra cache fields into the separate cache file
+        if self.bitbake_mode:
+            with open(self.extra_cachefile, "wb") as extra_cachefile:
+                extra_pickler = pickle.Pickler(extra_cachefile, \
+                                               pickle.HIGHEST_PROTOCOL)
+                for key, value in self.extra_depends_cache.iteritems():
+                    extra_pickler.dump(key)
+                    extra_pickler.dump(value)
+
         del self.depends_cache
+        del self.extra_depends_cache
 
     @staticmethod
     def mtime(cachefile):
         return bb.parse.cached_mtime_noerror(cachefile)
 
-    def add_info(self, filename, info, cacheData, parsed=None):
+    def add_info(self, filename, info, extra_info, cacheData, parsed=None):
         if not info.skipped:
             cacheData.add_from_recipeinfo(filename, info)
+            cacheData.add_from_extra_recipeinfo(filename, extra_info)
 
         if not self.has_cache:
             return
@@ -536,15 +601,20 @@ class Cache(object):
             if parsed:
                 self.cacheclean = False
             self.depends_cache[filename] = info
+            if self.bitbake_mode:
+                self.extra_depends_cache[filename] = extra_info
 
     def add(self, file_name, data, cacheData, parsed=None):
         """
         Save data we need into the cache
         """
-
         realfn = self.virtualfn2realfn(file_name)[0]
+        extra_info = None
         info = RecipeInfo.from_metadata(realfn, data)
-        self.add_info(file_name, info, cacheData, parsed)
+        if self.bitbake_mode:
+            extra_info = \
+                ExtraRecipeInfoFactory.from_metadata(self.bitbake_mode, data)
+        self.add_info(file_name, info, extra_info, cacheData, parsed)
 
     @staticmethod
     def load_bbfile(bbfile, appends, config):
@@ -610,6 +680,7 @@ class CacheData(object):
 
     def __init__(self, bitbake_mode):
         # Direct cache variables
+        self.bitbake_mode = bitbake_mode
         self.providers = defaultdict(list)
         self.rproviders = defaultdict(list)
         self.packages = defaultdict(list)
@@ -635,11 +706,13 @@ class CacheData(object):
         self.basetaskhash = {}
         self.hashfn = {}
         self.inherits = {}
+        self.fakerootenv = {}
+        self.fakerootdirs = {}
+
+# Extra cache fields
         self.summary = {}
         self.license = {}
         self.section = {}
-        self.fakerootenv = {}
-        self.fakerootdirs = {}
 
         # Indirect Cache variables (set elsewhere)
         self.ignored_dependencies = []
@@ -647,6 +720,12 @@ class CacheData(object):
         self.bbfile_priority = {}
         self.bbfile_config_priorities = []
 
+    def add_from_extra_recipeinfo(self, fn, extra_info):
+        if self.bitbake_mode:
+            self.summary[fn] = extra_info.summary
+            self.license[fn] = extra_info.license
+            self.section[fn] = extra_info.section
+
     def add_from_recipeinfo(self, fn, info):
         self.task_deps[fn] = info.task_deps
         self.pkg_fn[fn] = info.pn
@@ -705,8 +784,5 @@ class CacheData(object):
             self.basetaskhash[identifier] = taskhash
 
         self.inherits[fn] = info.inherits
-        self.summary[fn] = info.summary
-        self.license[fn] = info.license
-        self.section[fn] = info.section
         self.fakerootenv[fn] = info.fakerootenv
         self.fakerootdirs[fn] = info.fakerootdirs
bitbake/lib/bb/cooker.py +31 -13

100 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#5 lore raw
In reply to Liping Ke

Hi, all

Send twice with the modified subjects since those patches are introduced for image creator backend.

Thanks a lot!
criping

Quoted 42 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Liping Ke
Sent: Monday, May 09, 2011 2:40 PM
To: [email protected]
Subject: [poky] [PATCH 0/4][Image Creator]Put extra requested fields into different cache files

From: Liping Ke <[email protected]>

Below four patches are for putting extra requested fields inito different cache files instead of using only on bb_cache.dat. Now image creator need extra three fields. And in the future, there might be more similar requests. For each extra requestor, we will save the requested fields data into a separate cache files so that those who don't need it will not be impacted with larger fields and large data files.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/cache_impl
Browse:
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lke/cache_impl

Thanks,
Liping Ke <[email protected]>
---

Liping Ke (4):
Introduce new param bitbake_mode into Cache.py Split Cache Data Retrieve method from Data Fields Introduce Extra required fields for image creator Implement independent cache for Extra Cache Fields Request

 bitbake/lib/bb/cache.py  |  189
+++++++++++++++++++++++++++++++++++++---------
 bitbake/lib/bb/cooker.py |   55 ++++++++++----
 2 files changed, 193 insertions(+), 51 deletions(-)

_______________________________________________
poky mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/poky

author
#6 lore raw

Hi, Josh

Those patches are rebased with latest poky master today. I noticed Richard has changed the code of cache, making sure skipped info is saved for avoiding unnecessary parsing, so that the cache file will remain the same size each time. ( I found before this change, cache file kept increased).
I verified that our new introduced patch working with this latest cache changes.

Thanks a lot!
criping

Quoted 57 lines

-----Original Message-----
From: Ke, Liping
Sent: Monday, May 09, 2011 2:53 PM
To: Ke, Liping; [email protected]
Subject: RE: [poky] [PATCH 0/4][Image Creator]Put extra requested fields into different cache files

Hi, all

Send twice with the modified subjects since those patches are introduced for image creator backend.

Thanks a lot!
criping

Quoted 42 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Liping Ke
Sent: Monday, May 09, 2011 2:40 PM
To: [email protected]
Subject: [poky] [PATCH 0/4][Image Creator]Put extra requested fields into different cache files

From: Liping Ke <[email protected]>

Below four patches are for putting extra requested fields inito different cache files instead of using only on bb_cache.dat. Now image creator need extra three fields. And in the future, there might be more similar requests. For each extra requestor, we will save the requested fields data into a separate cache files so that those who don't need it will not be impacted with larger fields and large data files.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/cache_impl
Browse:
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lke/cache_impl

Thanks,
Liping Ke <[email protected]>
---

Liping Ke (4):
Introduce new param bitbake_mode into Cache.py Split Cache Data Retrieve method from Data Fields Introduce Extra required fields for image creator Implement independent cache for Extra Cache Fields Request

 bitbake/lib/bb/cache.py  |  189
+++++++++++++++++++++++++++++++++++++---------
 bitbake/lib/bb/cooker.py |   55 ++++++++++----
 2 files changed, 193 insertions(+), 51 deletions(-)

_______________________________________________
poky mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/poky

#7 lore raw
In reply to Liping Ke

Hi Liping,

Quoted 7 lines · Liping Ke

Below four patches are for putting extra requested fields inito different cache files instead of using only on bb_cache.dat. Now image creator need extra three fields. And in the future, there might be more similar requests. For each extra requestor, we will save the requested fields data into a separate cache files so that those who don't need it will not be impacted with larger fields and large data files.

Quoted 6 lines

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/cache_impl
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lke/cache_impl

Thanks,
Liping Ke <[email protected]>

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

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.

b) Could we rename "bitbake_mode" to "extracaches" or something? "bitbake_mode" is a bit too generic and meaningless.

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.

Cheers,

Richard

author
#8 lore raw

Hi, Richard,

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

criping

Quoted 11 lines

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).

Quoted 5 lines

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?

Quoted 2 lines

b) Could we rename "bitbake_mode" to "extracaches" or something? "bitbake_mode" is a bit too generic and meaningless.

Sure. It's nice.

Quoted 5 lines

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?

Quoted 3 lines

Cheers,

Richard

#9 lore raw
Quoted 8 lines · Liping
Quoted 8 lines

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:

Quoted 7 lines
Quoted 3 lines

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).

That's fine, your original series didn't seem to work quite like this though and looked like I'd get failures if I only applied the early patches from what I remember.

Quoted 10 lines
Quoted 5 lines

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?

I'm thinking that cache.py defines the class but the hob specific definition using that class to extend the cache data should be part of the hob codebase. In the future there may be external UIs calling into this code and needing this functionality and I'd prefer them not to each need to change cache.py.

Quoted 3 lines

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?

If you don't think this is realistic in the time available, I might be able to take a look at it.

Quoted 9 lines
Quoted 2 lines

b) Could we rename "bitbake_mode" to "extracaches" or something? "bitbake_mode" is a bit too generic and meaningless.

Sure. It's nice.

Quoted 5 lines

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.

Quoted 10 lines

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?

No, I mean can we could pass:

bitbake_mode = ['hob', 'autobuilder']

and it then uses three cache files so bitbake_mode would become a list rather than a single item.

Cheers,

Richard

author
#10 lore raw

Hi, Richard

Quoted 6 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

b).

Quoted 2 lines

But for c), because of the implantation algorithm I adopted, it's merged with extra cache data implementation (the biggest patch).

That's fine, your original series didn't seem to work quite like this though and looked like I'd get failures if I only applied the early patches from what I remember.

sure, I understand this. I will make sure that the series of patches works independently when resending the patch.

Quoted 12 lines
Quoted 8 lines
Quoted 6 lines

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?)

Quoted 2 lines

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

Quoted 8 lines
Quoted 1 line

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?

I'm thinking that cache.py defines the class but the hob specific definition using that class to extend the cache data should be part of the hob codebase. In the future there may be external UIs calling into this code and needing this functionality and I'd prefer them not to each need to change cache.py.

Hi, Richard, just a question here. You mean ext-hob-cache data will be a sub-class of cachy data? Inheritance here? We originally consider this, yet just failed to find a good way. Namedtuple has the static dict fields. So namedtuple class can't be extended. For inheritance, I must change the original cache.py implantation.
Just want to hear your suggestion here...

Quoted 9 lines
Quoted 2 lines

And also, if you think it is a must, could we split the task, for this phase, keep

it in the same file.

Quoted 1 line

And then refactory them in another patch later? Seems there're many tasks

for image creator? Seems the schedule is

Quoted 1 line

tight?

If you don't think this is realistic in the time available, I might be able to take a look at it.

Oh, I guess Jessica will re-arrange the schedule today... Seems for the task, there're many different understanding about the requirement at the very beginning... I will try to understand all the details before writing the code -:)

Quoted 7 lines

No, I mean can we could pass:

bitbake_mode = ['hob', 'autobuilder']

and it then uses three cache files so bitbake_mode would become a list rather than a single item.

OK, I understand this requirement now.
After we sync up today, I should have a clearer understanding about the requirement and I will redo the patch!

Thanks a lot for your help!
criping

Quoted 3 lines

Cheers,

Richard