From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH] libfdt: fdt_path_offset_*(): Fix handling of paths with options in them
Date: Fri, 29 May 2015 22:26:05 +1000 [thread overview]
Message-ID: <20150529122605.GC3664@voom.fritz.box> (raw)
In-Reply-To: <1432213252-30292-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]
On Thu, May 21, 2015 at 03:00:52PM +0200, Hans de Goede wrote:
> This is another approach at fixing the issues with paths with have options
> appended seperated by a ':' character.
>
> commit b4150b59ae ("libfdt: Add fdt_path_offset_namelen()")
>
> Is related to this, it allows the caller to specify to only look at part
> of the passed in path. But as experience with using this in the kernel has
> shown using this properly is quite hard since the options itself may have
> a '/' in them, also see the comment above the new fdt_path_next_seperator
> helper this commit adds.
>
> So this commit, which currently is being used by u-boot, instead simply
> teaches fdt_path_offset() to just do the right thing when it encounters
> paths with a ':' in them.
I dislike this - it's building into the core path handling something
related to how external things happen to glue extra options on there.
I also don't see why it's necessary. ':' shouldn't appear in paths,
so why can't you just strchr() for the first ':', pass the first path
to path_offset_namelen, and the last part to your option parsing code?
>
> Cc: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> libfdt/fdt_ro.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
> index a65e4b5..9efbcb2 100644
> --- a/libfdt/fdt_ro.c
> +++ b/libfdt/fdt_ro.c
> @@ -154,6 +154,25 @@ int fdt_subnode_offset(const void *fdt, int parentoffset,
> return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
> }
>
> +/*
> + * Find the next of path seperator, note we need to search for both '/' and ':'
> + * and then take the first one so that we do the rigth thing for e.g.
> + * "foo/bar:option" and "bar:option/otheroption", both of which happen, so
> + * first searching for either ':' or '/' does not work.
> + */
> +static const char *fdt_path_next_seperator(const char *path, int len)
> +{
> + const char *sep1 = memchr(path, '/', len);
> + const char *sep2 = memchr(path, ':', len);
> +
> + if (sep1 && sep2)
> + return (sep1 < sep2) ? sep1 : sep2;
> + else if (sep1)
> + return sep1;
> + else
> + return sep2;
> +}
> +
> int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
> {
> const char *end = path + namelen;
> @@ -164,7 +183,7 @@ int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
>
> /* see if we have an alias */
> if (*path != '/') {
> - const char *q = memchr(path, '/', end - p);
> + const char *q = fdt_path_next_seperator(path, end - p);
>
> if (!q)
> q = end;
> @@ -182,10 +201,10 @@ int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen)
>
> while (*p == '/') {
> p++;
> - if (p == end)
> + if (p == end || *p == ':')
> return offset;
> }
> - q = memchr(p, '/', end - p);
> + q = fdt_path_next_seperator(p, end - p);
> if (! q)
> q = end;
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-05-29 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 13:00 [PATCH] libfdt: fdt_path_offset_*(): Fix handling of paths with options in them Hans de Goede
[not found] ` <1432213252-30292-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-29 12:26 ` David Gibson [this message]
[not found] ` <20150529122605.GC3664-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-05-30 7:52 ` Hans de Goede
[not found] ` <55696C37.6090806-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-03 13:02 ` Peter Hurley
2015-07-02 7:16 ` David Gibson
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=20150529122605.GC3664@voom.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.