From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
Date: Fri, 30 Mar 2012 15:08:36 +0200 [thread overview]
Message-ID: <201203301508.37159.marex@denx.de> (raw)
In-Reply-To: <4F75AE66.1090205@keymile.com>
Dear Gerlando Falauto,
> On 03/29/2012 10:19 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> >
> > WD prodded me too long to review this patchset ;-D
>
> Well, better late than never! ;-)
>
> [...]
>
> >> +#if defined(CONFIG_CMD_NET)
> >> + else if (strcmp(name, "bootfile") == 0) {
> >> + copy_filename(BootFile, newval, sizeof(BootFile));
> >
> > Can you remove the camel-case here please?
>
> That's code I just moved around... Will do, sir.
Don't call me that way, makes me feel old :D
> >> + return 0;
> >> + }
> >> +#endif
> >> + return 0;
> >> +}
> >> +
>
> [...]
>
> >> --- a/include/search.h
> >> +++ b/include/search.h
> >> @@ -47,6 +47,13 @@ typedef struct entry {
> >>
> >> struct _ENTRY;
> >>
> >> /*
> >>
> >> + * Callback function to be called for checking whether the given change
> >> may + * be applied or not. Must return 0 for approval, 1 for denial.
> >> + */
> >> +typedef int (*apply_cb)(const char *name, const char *oldval,
> >> + const char *newval, int flag);
> >
> > Is the typedef really necessary ?
> >
> >[From your other email]
> >
> > I have to admit I'm not much of a fan of how you use this apply()
> > callback, is it really necessary?
>
> Why ask, if you already know the answer? :-)
>
> I'm not a big fan either, seemed like the easiest approach at the time.
> The idea was to keep the hastable (struct hsearch_data) as decoupled as
> possible from the environment (env_htab which is, in fact, the only
> instance of struct hsearch_data).
>
> What if the function pointer was stored within the hastable itself?
> Sort of a virtual method.
> This way we get rid of the typedef and the function pointer as a
> parameter altogether.
> The callback parameter then just becomes a boolean value (meaning,
> do/don't call the callback function stored within the hashtable itself).
> I like that much better. What do you think?
Don't we always use only one (this callback) function?
>
> [...]
>
> >> /* Flags for himport_r() */
> >> #define H_NOCLEAR 1 /* do not clear hash table before
> >
> > importing */
> >
> >> +#define H_FORCE 2 /* overwrite read-only/write-once
> >
> > variables */
> >
> > Make this 1<< x please.
>
> OK.
>
> >> #endif /* search.h */
> >>
> >> diff --git a/lib/hashtable.c b/lib/hashtable.c
> >> index abd61c8..75b9b07 100644
> >> --- a/lib/hashtable.c
> >> +++ b/lib/hashtable.c
> >> @@ -603,6 +603,22 @@ ssize_t hexport_r(struct hsearch_data *htab, const
> >> char sep, * himport()
> >>
> >> */
> >>
> >> +/* Check whether variable name is amongst vars[] */
> >> +static int process_var(const char *name, int nvars, char * const
> >> vars[])
> >
> > You mean check_var()?
>
> I mean is_var_in_set_or_is_set_empty().
Nice name :)
> Sorry, I'm very, very bad at picking function names.
> Any suggestion?
The above is quite descriptive ... maybe is_var_in_set() ? And hey, don't be
sorry, you're doing very good job!
>
> >> +{
> >> + int i = 0;
> >> + /* No variables specified means process all of them */
> >> + if (nvars == 0)
> >> + return 1;
> >> +
> >> + for (i = 0; i< nvars; i++) {
> >> + if (!strcmp(name, vars[i]))
> >> + return 1;
> >> + }
> >> + debug("Skipping non-listed variable %s\n", name);
> >> + return 0;
> >> +}
> >> +
> >>
> >> /*
> >>
> >> * Import linearized data into hash table.
> >> *
> >>
> >> @@ -639,7 +655,9 @@ ssize_t hexport_r(struct hsearch_data *htab, const
> >> char sep, */
> >>
> >> int himport_r(struct hsearch_data *htab,
> >>
> >> - const char *env, size_t size, const char sep, int flag)
> >> + const char *env, size_t size, const char sep, int flag,
> >> + int nvars, char * const vars[],
> >> + apply_cb apply)
> >>
> >> {
> >>
> >> char *data, *sp, *dp, *name, *value;
> >>
> >> @@ -726,6 +744,8 @@ int himport_r(struct hsearch_data *htab,
> >>
> >> *dp++ = '\0'; /* terminate name */
> >>
> >> debug("DELETE CANDIDATE: \"%s\"\n", name);
> >>
> >> + if (!process_var(name, nvars, vars))
> >> + continue;
> >>
> >> if (hdelete_r(name, htab) == 0)
> >>
> >> debug("DELETE ERROR
> >
> > ##############################\n");
> >
> >> @@ -743,10 +763,31 @@ int himport_r(struct hsearch_data *htab,
> >>
> >> *sp++ = '\0'; /* terminate value */
> >> ++dp;
> >>
> >> + /* Skip variables which are not supposed to be treated */
> >> + if (!process_var(name, nvars, vars))
> >> + continue;
> >> +
> >>
> >> /* enter into hash table */
> >> e.key = name;
> >> e.data = value;
> >
> > Do you need to do this if you eventually later figure out you have no
> > apply() callback and you did this for no reason?
>
> You mean calling process_var()? It's two separate things.
>
> One, filter out the variables that were not asked to be processed, if
> there were any (call to process_var())
> Two, check whether the new value is acceptable and/or apply it (call
> apply())
> You could have none, either, or both.
>
> Or else, if you mean moving the e.key = name, e.data = value
> assignments, you're right, they should be moved down (but in that case
> it would be because the apply function fails, not because it's not
> present -- default case is always successful).
Yep, that's what I meant. OK
>
> >> + /* if there is an apply function, check what it has to say */
> >> + if (apply != NULL) {
> >> + debug("searching before calling cb function"
> >> + " for %s\n", name);
> >> + /*
> >> + * Search for variable in existing env, so to pass
> >> + * its previous value to the apply callback
> >> + */
> >> + hsearch_r(e, FIND,&rv, htab);
> >> + debug("previous value was %s\n", rv ? rv->data : "");
> >> + if (apply(name, rv ? rv->data : NULL, value, flag)) {
> >> + debug("callback function refused to set"
> >> + " variable %s, skipping it!\n", name);
> >> + continue;
> >> + }
> >> + }
> >> +
> >>
> >> hsearch_r(e, ENTER,&rv, htab);
> >> if (rv == NULL) {
> >>
> >> printf("himport_r: can't insert \"%s=%s\" into hash
> >
> > table\n",
>
> Thank you,
> Gerlando
next prev parent reply other threads:[~2012-03-30 13:08 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-18 16:49 [U-Boot] [PATCH v1 0/5] env: handle special variables and selective env default Gerlando Falauto
2011-11-18 16:49 ` [U-Boot] [PATCH v1 1/5] serial: cosmetic checkpatch compliance Gerlando Falauto
2011-11-18 20:04 ` Mike Frysinger
2011-12-05 21:47 ` Wolfgang Denk
2011-11-18 16:49 ` [U-Boot] [PATCH v1 2/5] serial: constify serial_assign() Gerlando Falauto
2011-11-18 20:03 ` Mike Frysinger
2011-12-05 21:48 ` Wolfgang Denk
2011-11-18 16:49 ` [U-Boot] [PATCH v1 3/5] env: unify logic to check and apply changes Gerlando Falauto
2011-12-07 1:50 ` Simon Glass
2011-11-18 16:49 ` [U-Boot] [PATCH v1 4/5] env: check and apply changes on delete/destroy Gerlando Falauto
2011-11-18 16:49 ` [U-Boot] [PATCH v1 5/5] env: make "env default" selective, check and apply Gerlando Falauto
2011-12-07 13:30 ` [U-Boot] [PATCH v2 0/3] env: handle special variables and selective env default Gerlando Falauto
2011-12-07 13:30 ` [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes Gerlando Falauto
2011-12-07 22:02 ` Simon Glass
2011-12-08 5:45 ` Mike Frysinger
2011-12-12 9:32 ` Gerlando Falauto
2011-12-12 12:18 ` Wolfgang Denk
2011-12-12 13:38 ` Gerlando Falauto
2011-12-12 13:50 ` Wolfgang Denk
2011-12-12 16:24 ` Simon Glass
2012-03-29 20:19 ` Marek Vasut
2012-03-30 13:00 ` Gerlando Falauto
2012-03-30 13:08 ` Marek Vasut [this message]
2012-03-30 13:22 ` Gerlando Falauto
2012-03-30 13:55 ` Marek Vasut
2012-03-30 14:03 ` Gerlando Falauto
2012-03-30 14:28 ` Marek Vasut
2012-03-30 17:00 ` Gerlando Falauto
2011-12-07 13:30 ` [U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy Gerlando Falauto
2011-12-07 22:02 ` Simon Glass
2011-12-12 9:32 ` Gerlando Falauto
2011-12-12 13:08 ` Wolfgang Denk
2011-12-12 13:52 ` Gerlando Falauto
2011-12-12 19:19 ` Wolfgang Denk
2011-12-07 13:30 ` [U-Boot] [PATCH v2 3/3] env: make "env default" selective, check and apply Gerlando Falauto
2011-12-07 22:02 ` Simon Glass
2011-12-12 9:33 ` Gerlando Falauto
2011-12-12 13:10 ` Wolfgang Denk
2012-03-29 20:25 ` Marek Vasut
2012-03-30 13:00 ` Gerlando Falauto
2012-03-30 13:09 ` Marek Vasut
2012-03-30 13:25 ` Gerlando Falauto
2012-04-02 18:26 ` [U-Boot] [PATCH v3 0/6] env: handle special variables and selective env default Gerlando Falauto
2012-08-09 20:17 ` Wolfgang Denk
2012-08-09 22:19 ` Gerlando Falauto
2012-08-09 22:26 ` Wolfgang Denk
2012-08-10 8:53 ` Holger Brunck
2012-08-10 18:08 ` Wolfgang Denk
2012-08-13 7:23 ` Holger Brunck
2012-08-13 10:11 ` Wolfgang Denk
2012-08-24 10:18 ` Gerlando Falauto
2012-08-24 15:11 ` Marek Vasut
2012-04-02 18:26 ` [U-Boot] [PATCH v3 1/6] env: unify logic to check and apply changes Gerlando Falauto
2012-04-02 18:56 ` Marek Vasut
2012-04-02 20:39 ` Gerlando Falauto
2012-04-02 20:50 ` Marek Vasut
2012-04-02 18:26 ` [U-Boot] [PATCH v3 2/6] env: make himport_r() selective on variables Gerlando Falauto
2012-04-02 18:57 ` Marek Vasut
2012-04-02 20:43 ` Gerlando Falauto
2012-04-04 7:41 ` Simon Glass
2012-04-02 18:26 ` [U-Boot] [PATCH v3 3/6] env: add check/apply logic to himport_r() Gerlando Falauto
2012-04-02 19:00 ` Marek Vasut
2012-04-02 19:01 ` Marek Vasut
2012-04-02 20:44 ` Gerlando Falauto
2012-04-02 20:51 ` Marek Vasut
2012-04-02 18:26 ` [U-Boot] [PATCH v3 4/6] env: check and apply changes on delete/destroy Gerlando Falauto
2012-04-02 19:01 ` Marek Vasut
2012-04-02 18:26 ` [U-Boot] [PATCH v3 5/6] env: make "env default" selective, check and apply Gerlando Falauto
2012-04-02 19:04 ` Marek Vasut
2012-04-02 18:26 ` [U-Boot] [PATCH v3 6/6] env: delete selected vars not present in imported env Gerlando Falauto
2012-04-02 19:06 ` Marek Vasut
2012-04-02 20:45 ` Gerlando Falauto
2012-04-02 21:00 ` Marek Vasut
2012-08-24 10:11 ` [U-Boot] [PATCH v4 0/7] env: handle special variables and selective env default Gerlando Falauto
2012-08-24 10:11 ` [U-Boot] [PATCH v4 1/7] env: cosmetic: drop assignment i = iomux_doenv() Gerlando Falauto
2012-08-24 14:44 ` Marek Vasut
2012-09-18 19:05 ` [U-Boot] [U-Boot, v4, " Tom Rini
2012-08-24 10:11 ` [U-Boot] [PATCH v4 2/7] env: unify logic to check and apply changes Gerlando Falauto
2012-08-24 14:48 ` Marek Vasut
2012-08-24 10:11 ` [U-Boot] [PATCH v4 3/7] env: make himport_r() selective on variables Gerlando Falauto
2012-08-24 14:50 ` Marek Vasut
2012-08-24 10:11 ` [U-Boot] [PATCH v4 4/7] env: add check/apply logic to himport_r() Gerlando Falauto
2012-08-24 14:52 ` Marek Vasut
2012-08-24 10:11 ` [U-Boot] [PATCH v4 5/7] env: check and apply changes on delete/destroy Gerlando Falauto
2012-08-24 14:53 ` Marek Vasut
2012-08-24 10:11 ` [U-Boot] [PATCH v4 6/7] env: make "env default" selective, check and apply Gerlando Falauto
2012-08-24 14:56 ` Marek Vasut
2012-08-24 15:10 ` Gerlando Falauto
2012-08-24 21:10 ` Marek Vasut
2012-08-27 7:36 ` Gerlando Falauto
2012-08-27 9:57 ` Marek Vasut
2012-09-02 11:58 ` Wolfgang Denk
2012-08-24 10:11 ` [U-Boot] [PATCH v4 7/7] env: delete selected vars not present in imported env Gerlando Falauto
2012-08-24 14:58 ` Marek Vasut
2012-08-24 15:16 ` Gerlando Falauto
2012-08-24 21:12 ` Marek Vasut
2012-08-27 7:45 ` Gerlando Falauto
2012-09-02 12:01 ` Wolfgang Denk
2012-09-03 7:34 ` Gerlando Falauto
2012-08-27 7:53 ` [U-Boot] [PATCH v5 " Gerlando Falauto
2012-08-27 10:02 ` Marek Vasut
2012-09-02 11:59 ` [U-Boot] [PATCH v4 0/7] env: handle special variables and selective env default Wolfgang Denk
2012-09-02 16:13 ` Marek Vasut
2012-09-03 7:33 ` Gerlando Falauto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201203301508.37159.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox