From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [Automated-testing] [PATCH 1/3] lib/tst_kconfig: Rewrite the parser internals
Date: Wed, 21 Oct 2020 16:31:30 +0200 [thread overview]
Message-ID: <20201021143130.GA21944@x230> (raw)
In-Reply-To: <20201021141157.GC10861@yuki.lan>
Hi,
> > >> lines first to remove whitespace issues and expose the parser to all
> > >> possible variable name symbols and values instead of just the ones which
> > >> appear in our current tests.
> > > I guess that it's techincally possible to have a whitespaces there, but
> > > will not happen unless you hand-edit the config file before compilation,
> > > which I doubt will ever happen.
> > It can also happen if someone has their own script to modify the
> > config. At any rate, if you are confident that it will never happen then
> > there should be no problem failing hard if it does.
> It would be probably easier to eat the whitespace around the = if
> present. But still I would ignore anything that isn't correct variable
> assignment, since such config would fail kernel compilation anyways.
+1
+ I use ./scripts/config --enable | --disable ... to avoid problems with
incorrect config.
> > >> > +
> > >> > + if (kconfig_parse_line(line, vars, vars_len))
> > >> > + vars_found++;
> > >> > + if (vars_found == vars_len)
> > >> > + goto exit;
> > >> > }
> > >> Generally, this approach seems like to result in spurious TCONFs. We
> > >> need to properly parse the file and fail if some line can't be
> > >> interpreted.
> > > Well we do expect well formatted .config file from a start, if you hand
> > > edit it and put whitespaces into unexpected places more things may
> > > fail.
> > Kernel build system seems to have no problem with it. More generally
> > though we should fail hard if there is something unexpected, not produce
> > TCONF which people don't check.
> Even if we do I do not think that we should care about anything but
> syntactically correct input, since if you modify the file after kernel
> compilation you have lost anyways.
+1
Kind regards,
Petr
next prev parent reply other threads:[~2020-10-21 14:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 10:09 [LTP] [PATCH 0/3] Add support for kconfig constraints Cyril Hrubis
2020-10-20 10:09 ` [LTP] [PATCH 1/3] lib/tst_kconfig: Rewrite the parser internals Cyril Hrubis
2020-10-21 9:46 ` Richard Palethorpe
2020-10-21 10:06 ` Cyril Hrubis
2020-10-21 12:39 ` Richard Palethorpe
2020-10-21 14:11 ` Cyril Hrubis
2020-10-21 14:31 ` Petr Vorel [this message]
2020-10-22 8:09 ` Richard Palethorpe
2020-10-22 8:53 ` Cyril Hrubis
2020-10-20 10:09 ` [LTP] [PATCH 2/3] lib: Add generic boolean expression parser and eval Cyril Hrubis
2020-10-21 16:34 ` Richard Palethorpe
2020-10-21 16:36 ` Richard Palethorpe
2020-10-21 18:20 ` Cyril Hrubis
2020-10-22 7:55 ` Richard Palethorpe
2020-10-22 8:57 ` Cyril Hrubis
2020-10-22 10:28 ` Richard Palethorpe
2020-10-20 10:09 ` [LTP] [PATCH 3/3] lib/tst_kconfig: Make use of boolean expression eval Cyril Hrubis
2020-10-22 8:38 ` Richard Palethorpe
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=20201021143130.GA21944@x230 \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/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