[PATCH 2/3] Add registry for garbage collection on update finalization

[Andreas J. Reichel]

From: Andreas Reichel <andreas.r...@siemens.com>

Provide possibility to register user variables that are deleted
on finalization of an update.

Signed-off-by: Andreas Reichel <andreas.r...@siemens.com>
---
env/env_api.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
include/ebgenv.h | 8 ++++++++
include/env_api.h | 5 +++++
3 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/env/env_api.c b/env/env_api.c
index 75695d1..fa32a15 100644
--- a/env/env_api.c
+++ b/env/env_api.c
@@ -240,10 +240,55 @@ int ebg_env_close(ebgenv_t *e)
return 0;
}

-int ebg_env_finalize_update(ebgenv_t *e) {
+int ebg_env_gc_register_var(ebgenv_t *e, char *key)
+{
+ GC_ITEM **pgci;
+ pgci = (GC_ITEM **)&e->gc_registry;
+
+ if (!key) {
+ return EINVAL;
+ }
+ while (*pgci) {
+ pgci = &((*pgci)->next);
+ }
+ *pgci = (GC_ITEM *)calloc(1, sizeof(GC_ITEM));
+ if (!*pgci) {
+ return ENOMEM;
+ }
+ if (asprintf(&((*pgci)->key), "%s", key) == -1) {
+ free(*pgci);
+ *pgci = NULL;
+ return ENOMEM;
+ }
+ return 0;
+}
+
+int ebg_env_finalize_update(ebgenv_t *e)
+{
if (!e->bgenv || !((BGENV *)e->bgenv)->data) {
return EIO;
}
+
+ GC_ITEM **pgci, *tmp;
+ uint8_t *udata;
+
+ pgci = (GC_ITEM **)&e->gc_registry;
+ udata = ((BGENV *)e->bgenv)->data->userdata;
+ while (*pgci) {
+ if ((*pgci)->key) {
+ uint8_t *var;
+ var = bgenv_find_uservar(udata, (*pgci)->key);
+ if (var) {
+ bgenv_del_uservar(udata, var);
+ }
+ free((*pgci)->key);
+ }
+ tmp = (*pgci)->next;
+ free(*pgci);
+ *pgci = NULL;
+ pgci = &tmp;
+ }
+
((BGENV *)e->bgenv)->data->in_progress = 0;
((BGENV *)e->bgenv)->data->ustate = USTATE_INSTALLED;
return 0;
diff --git a/include/ebgenv.h b/include/ebgenv.h
index 46e692c..8b158b7 100644
--- a/include/ebgenv.h
+++ b/include/ebgenv.h
@@ -35,6 +35,7 @@

typedef struct {
void *bgenv;
+ void *gc_registry;
} ebgenv_t;

/** @brief Tell the library to output information for the user.
@@ -128,6 +129,13 @@ int ebg_env_setglobalstate(ebgenv_t *e, uint16_t ustate);
*/
int ebg_env_close(ebgenv_t *e);

+/** @brief Register a variable that will be deleted on finalize
+ * @param e A pointer to an ebgenv_t context.
+ * @param key A string containing the variable key
+ * @return 0 on success, errno on failure
+ */
+int ebg_env_gc_register_var(ebgenv_t *e, char *key);
+
/** @brief Finalizes a currently running update procedure
* @param e A pointer to an ebgenv_t context.
* @return 0 on success, errno on failure
diff --git a/include/env_api.h b/include/env_api.h
index 4d652ff..ec73a64 100644
--- a/include/env_api.h
+++ b/include/env_api.h
@@ -66,6 +66,11 @@ typedef struct {
BG_ENVDATA *data;
} BGENV;

+typedef struct gc_item {
+ char *key;
+ struct gc_item *next;
+} GC_ITEM;
+
extern void bgenv_be_verbose(bool v);

extern char *str16to8(char *buffer, wchar_t *src);
--
2.16.2

[Andreas J. Reichel]

From: Andreas Reichel <andreas.r...@siemens.com>

This patch series fixes a bug regarding user variables.

Furthermore it introduces a garbage collector to
ebg_env_finalize_update, so that the user can register arbitrary user
variables, which automatically get deleted upon finalization.

Signed-off-by: Andreas Reichel <andreas.r...@siemens.com>

Andreas Reichel (3):
Bugfix: Don't map non-existing user variables
Add registry for garbage collection on update finalization
Tests: Add test for finalization garbage collector

env/env_api.c | 47 +++++++++++++++++++++++++++++++++++++-
env/env_api_fat.c | 3 +++
env/uservars.c | 4 ++++
include/ebgenv.h | 8 +++++++
include/env_api.h | 5 ++++
tools/tests/test_ebgenv_api.c | 53 ++++++++++++++++++++++++++++++++++++++++++-
6 files changed, 118 insertions(+), 2 deletions(-)

--
2.16.2

[Jan Kiszka]

Is it possible that key is NULL? Looks like you are rejecting that case
in the registration function.

This reads to me like "garbage-collect register var". Shouldn't it be
"register garbage-collected var" (register_gc_var)?

> +
> /** @brief Finalizes a currently running update procedure
> * @param e A pointer to an ebgenv_t context.
> * @return 0 on success, errno on failure
> diff --git a/include/env_api.h b/include/env_api.h
> index 4d652ff..ec73a64 100644
> --- a/include/env_api.h
> +++ b/include/env_api.h
> @@ -66,6 +66,11 @@ typedef struct {
> BG_ENVDATA *data;
> } BGENV;
>
> +typedef struct gc_item {
> + char *key;
> + struct gc_item *next;
> +} GC_ITEM;
> +
> extern void bgenv_be_verbose(bool v);
>
> extern char *str16to8(char *buffer, wchar_t *src);
>

Jan

[Andreas Reichel]

Oh you are right.

--
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas...@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

[Andreas Reichel]

On Mon, Mar 19, 2018 at 06:44:29PM +0800, Jan Kiszka wrote:

> > +int ebg_env_gc_register_var(ebgenv_t *e, char *key);
>
> This reads to me like "garbage-collect register var". Shouldn't it be
> "register garbage-collected var" (register_gc_var)?

The logic is to have categoric naming from left to right.
For example, ebg_env... are functions belonging to ebg environment.
The same way ebg_env_gc are all functions belonging to the garbage
collector. Just because we have only one does not make that a
bad idea to me.

> > extern char *str16to8(char *buffer, wchar_t *src);
> >
>
> Jan

[Jan Kiszka]

On 2018-03-19 20:26, Andreas Reichel wrote:
> On Mon, Mar 19, 2018 at 06:44:29PM +0800, Jan Kiszka wrote:
>>> +int ebg_env_gc_register_var(ebgenv_t *e, char *key);
>>
>> This reads to me like "garbage-collect register var". Shouldn't it be
>> "register garbage-collected var" (register_gc_var)?
>
> The logic is to have categoric naming from left to right.
> For example, ebg_env... are functions belonging to ebg environment.
> The same way ebg_env_gc are all functions belonging to the garbage
> collector. Just because we have only one does not make that a
> bad idea to me.

Ok, that depends on the POV, apparently. I wouldn't have a expected an
"ebg environment - garbage collector" subsystem.

Jan