[gentoo-soc] Re: [GSoC] The macros in your proposal

[André Erdmann]

Hi Nicolas,

2016-03-31 0:13 GMT+02:00 Nicolas Sebrecht <nicolas.s-dev@×××××××.net>:
>   Hi André,
>
> I'm mentor in the Gentoo org and I'd like to know more on your proposal.
>
> You intend to introduce a macro system in the soft and make it quite
> central. Did you consider using a (mini-) DSL (based on Python) instead?
>
> What would be the pros and cons for both?
>

The term 'macro', as I've used it in my proposal, might be a bit misleading.
It just means "statement that expands to something (that is usually bigger)".

An external DSL is exactly what I have planned.

Basic instructions would be very simple in this language::

   <statement>             # <effective decision(s)>

   enable  A [A'...]       # CONFIG_A={y}[, CONFIG_A'={y} ...]
   module  B               # CONFIG_B={m}
   disable C               # CONFIG_C={n} ("# CONFIG_C is not set")

   enable-or-module D      # CONFIG_D={y,m}
   include <name|file>     # expands to statements from <name|file>
   exclude <name|file>     # expands to statements from <name|file>, negated

The first group of instructions exists already in the original project [0],
and I assume tristate-type kconfig symbols in this and the following examples.

The left side ("<statemtent>") is what users write(*),
and the right side reflects the "immediate" decisions made by the program.
Immediate insofar as user decisions need to be propagated,
if B={m} and B depends on P, then P must be y or m.
And if P depends on C and C={n} due to user decision,
then no kernel configuration can be created because of a conflict
(C = C_user & C_P = {y,m} & {n} = {}, no decision can be made).
But that's a different subject I'm going to address during the first weeks
(probably with an AC-3-inspired algorithm).

(*) usually in the "[options]" section of the settings ini file,
which will then become an ini-alike file, because the
"<statements>" don't need to adhere to the ini format


However, I plan to add conditional statements,
which is where the language gets a bit more complex::

   <statement> [<postfix condition>]

   # A={y} if the kconfig symbol A is defined,
   # and B={y} otherwise (in which case the kconfig symbol B has to be known)
   enable A if exists
   enable B if not ^above

   # C={y}, depending on kernel release version and architecture
   enable C if kver >= 3 and arch == x86_64

   # D={y} if any modalias identifier matches, else leave D unmodified
   enable D if modalias-match pci:... pci:...

   # E={y} if compound condition matches, else leave E unmodified
   enable E if $some_parameter == "value" [and (...) or (...)]

which is why I would implement a parser with ply or pyparsing.

The main use case of the conditional statements are files that get included
via the "include"/"exclude" instructions in the settings file.
These files - I called them "macro files" or "feature set" files
in the proposal - originate from various sources:

   * kernelconfig itself, in the form of:

     * hardware detection, a generated "enable _ if modalias-match _"
feature set file

     * commonly used config option blocks,
       e.g. an "I/O scheduler" feature set that prefers BFQ if that exists,
       and falls back to CFQ otherwise

   * package management,
     either generated from CONFIG_CHECK,
     or written by package maintainers/contributors
     ("better", because it'd be more accurate)

None of these sources involve end users directly, so it would be possible
to use a different language here (say, XML or even Python) and restrict
the settings file to basic instructions only, but I like the idea of having
a uniform method, which would also make user contributions easier.

I hope that answers your questions and provides a better insight into the
project ;-)


Regards,
André Erdmann

[0] https://github.com/Calchan/kernelconfig