git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] userdiff: Fix some corner cases in dts regex

From
Stephen Boyd <sboyd@kernel.org>
Date
Oct 8, 2019, 14:43 UTC
Message-ID
<20191008144306.B2B0820659@mail.kernel.org>
In-Reply-To
<c3a054d9-2646-e440-40c5-b0aecf21e690@kdbg.org>
Quoting Johannes Sixt (2019-10-05 07:09:11)
Show 16 quoted lines
> Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> > While reviewing some dts diffs recently I noticed that the hunk header
> > logic was failing to find the containing node. This is because the regex
> > doesn't consider properties that may span multiple lines, i.e.
> > 
> >       property = <something>,
> >                  <something_else>;
> 
> What if the property spans more than two lines?
> 
>         property = <something>,
>                    more,
>                    <something_else>;
> 
> Can the second line "more," begin with a word, or are the angle brackets
> mandatory?

Angle brackets aren't mandatory, but it is very odd to have a property with mixed numbers and strings because parsing becomes difficult.

Show 42 quoted lines
> 
> I understand that the continuation lines can begin with a word when the
> property is an expression that is distributed over a number of lines.
> Such continuation lines could be picked up as hunk headers.
> 
> But I don't want to complicate things: The hunk header patterns do not
> have to be perfect; it is sufficient when they are helpful in a good
> majority of cases that occur in practice.
> 
> > and it got hung up on comments inside nodes that look like the root node
> > because they start with '/*'. Add tests for these cases and update the
> > regex to find them. Maybe detecting the root node is too complicated but
> > forcing it to be a backslash with any amount of whitespace up to an open
> > bracket seemed OK. I tried to detect that a comment is in-between the
> > two parts but I wasn't happy so I just dropped it.
> > 
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Frank Rowand <frowand.list@gmail.com>
> > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > ---
> >  t/t4018/dts-nodes-multiline-prop | 12 ++++++++++++
> >  t/t4018/dts-root                 |  2 +-
> >  t/t4018/dts-root-comment         |  8 ++++++++
> >  userdiff.c                       |  3 ++-
> >  4 files changed, 23 insertions(+), 2 deletions(-)
> >  create mode 100644 t/t4018/dts-nodes-multiline-prop
> >  create mode 100644 t/t4018/dts-root-comment
> > 
> > diff --git a/t/t4018/dts-nodes-multiline-prop b/t/t4018/dts-nodes-multiline-prop
> > new file mode 100644
> > index 000000000000..f7b655935429
> > --- /dev/null
> > +++ b/t/t4018/dts-nodes-multiline-prop
> > @@ -0,0 +1,12 @@
> > +/ {
> > +     label_1: node1@ff00 {
> > +             RIGHT@deadf00,4000 {
> > +                     multilineprop = <3>,
> > +                                     <4>;
> 
> You could insert more lines to demonstrate that "<x>," on a line by
> itself is not picked up.
Maybe I should add another test?
Show 20 quoted lines
> 
> > +
> > +
> > +> +                  ChangeMe = <0xffeedd00>;
> 
> Sufficient distance to the incorrect candidates above. Good.
> 
> > +             };
> > +     };
> > +};
> > diff --git a/t/t4018/dts-root b/t/t4018/dts-root
> > index 2ef9e6ffaa2c..4353b8220c91 100644
> > --- a/t/t4018/dts-root
> > +++ b/t/t4018/dts-root
> > @@ -1,4 +1,4 @@
> > -/RIGHT { /* Technically just supposed to be a slash */
> > +/ { RIGHT /* Technically just supposed to be a slash and brace */
> 
> Do I understand correctly that the updated form, "/ {", is the common
> way to spell a root node, but "/" or "/word" are not?

Correct. A root node is '/' and the '{' opens the node. There is the possibility of something like '/delete-node nodename;' or '/delete-property property;', where the latter exists inside some node. The regex would need to avoid all of those.

Show 14 quoted lines
> 
> >       #size-cells = <1>;
> >  
> >       ChangeMe = <0xffeedd00>;
> > diff --git a/t/t4018/dts-root-comment b/t/t4018/dts-root-comment
> > new file mode 100644
> > index 000000000000..333a625c7007
> > --- /dev/null
> > +++ b/t/t4018/dts-root-comment
> > @@ -0,0 +1,8 @@
> > +/ { RIGHT /* Technically just supposed to be a slash and brace */
> 
> Devil's advocate here: insert ';' or '=' in the comment, and the line
> would not be picked up. Does that hurt in practice?
I don't think it hurts in practice so I'd like to ignore it.
Show 24 quoted lines
> 
> > +     #size-cells = <1>;
> > +
> > +     /* This comment should be ignored */
> > +
> > +     some-property = <40+2>;
> > +     ChangeMe = <0xffeedd00>;
> > +};
> > diff --git a/userdiff.c b/userdiff.c
> > index 86e3244e15dd..651b56caec56 100644
> > --- a/userdiff.c
> > +++ b/userdiff.c
> > @@ -25,8 +25,9 @@ IPATTERN("ada",
> >        "|=>|\\.\\.|\\*\\*|:=|/=|>=|<=|<<|>>|<>"),
> >  PATTERNS("dts",
> >        "!;\n"
> > +      "!.*=.*\n"
> 
> This behaves the same way as just
> 
>         "!=\n"
> 
> no?
> 

Not exactly. Properties don't always get assigned. There are boolean properties that can be tested for by the presence of some string with an ending semi-colon, like 'this-is-true;'. If we just check for not equal to a line with a semicolon and newline then we'll see boolean properties. Should I add that as another test?

Previous: Johannes SixtNext: Johannes Sixt
Message 3 of 5 in “userdiff: Fix some corner cases in dts regex”
  1. userdiff: Fix some corner cases in dts regexStephen Boyd, Oct 4, 2019
  2. Johannes SixtOct 5, 2019
  3. Stephen BoydOct 8, 2019
  4. Johannes SixtOct 12, 2019
  5. Stephen BoydOct 16, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.