[LTP] [Automated-testing] [PATCH 1/3] lib/tst_kconfig: Rewrite the parser internals

Petr Vorel pvorel@suse.cz
Wed Oct 21 16:31:30 CEST 2020


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


More information about the ltp mailing list