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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).