[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Kconfig: add documentation
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] Kconfig: add documentation |
Date: |
Wed, 13 Feb 2019 08:45:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Paolo Bonzini <address@hidden> writes:
> On 12/02/19 10:08, Markus Armbruster wrote:
>> Please wrap your lines at column 70 or so. Humans tend to have trouble
>> following long lines with their eyes (I sure do). Typographic manuals
>> suggest to limit columns to roughly 60 characters for exactly that
>> reason[*].
>
> Yup, fixed in v2.
>
>>> +Each QEMU target enables a subset of the boards, devices and buses that
>>> are included
>>> +in QEMU's source code. As a result, each QEMU executable only links a
>>> small subset
>>
>> Really? Hmm...
>>
>> $ size aarch64-softmmu/qemu-system-aarch64
>> text data bss dec hex filename
>> 19183216 7200124 592732 26976072 19b9f48
>> aarch64-softmmu/qemu-system-aarch64
>> $ size -t `find -name \*.o `| grep TOT
>> 92713559 18652227 1183961440 1295327226 4d351ffa
>> (TOTALS)
>>
>> Yep, really.
>
> Haha. :)
>
>>> + Optionally, a condition for applying the default value can be added with
>>> + ``if``. A config option can have any number of default values (usually,
>>> if more than
>>> + one default is present, they will have different conditions). If multiple
>>> + default values satisfy their condition, only the first defined one is
>>> active.
>>
>> Hmm. Is "multiple default values, first one wins" a healthy state?
>> How obvious is "first defined" to humans?
>
> It certainly helps that we never have more than one default. :)
True!
> I could also be persuaded to remove "default n", so that multiple
> "default y" clauses are just an OR of the conditions and the ordering
> does not matter.
I'm looking for something that doesn't involve too much global
reasoning.
"All default directives must provide the same value; their conditions
are ORed" feels fine to me. Order doesn't matter then. "if <expr>"
really means "if", not "if-and-only-if", and that's fine.
Additionally permitting an *unconditional* default with the negated
value would still be okay, I guess. But I'd do that only when we have a
use.
> Are multiple "default y" clauses useful? They were there in earlier
> versions of the patches, for now "imply" has removed the need
> everywhere. However, I'm not sure it's a good idea to remove them
> altogether before we try to extend Kconfig to more features. (A
> secondary effect of the documentation is to clarify the current scope of
> Kconfig).
My general advice would be YAGNI. However, keeping currently unused
features around while we grow Kconfig makes sense to me.
>>> +**reverse default** (weak reverse dependency): ``imply <symbol> [if
>>> <expr>]``
>>
>> If "reverse default" can be regarded as weak reverse dependency, could
>> "default value" be regarded as weak (forward) dependency?
>
> "default n if" could, but we never use it. This also shows how we use
> the language in a very limited way, according to the very simple rules
> in the second part of the document; but even Linux only has a handful of
> occurrences of "default n if".
>
>>> +
>>> + This is similar to ``select`` as it applies a lower limit of ``y`` to
>>> another
>>> + symbol. However, the lower limit is only a default and the "implied"
>>> symbol's
>>> + value may still be set to ``n`` from a ``default-configs/*.mak`` files.
>>> The
>>
>> I'm afraid I don't get "lower limit". What's the ordering relation?
>
> False < true, so "lower limit of y" means "tries to force to y". The
> difference is that a contradiction is ignored by "imply" (and then the
> symbol remains at n), while it causes a build error for "select".
Can we use this explanation to rephrase the documentation in simpler
language?
Let me summarize to see whether I got it. Please correct
misunderstandings.
* "depends on" forces to false unless condition is met
* "select" forces to true if condition is met
* Contradictions between "depends on" and "select" are rejected
* If neither applies, default-configs/*.mak may supply the value
* If it doesn't, "default" / "imply" supply the value if condition is
met
* What about contradictions between "default" / "imply"?
PS: Thanks for writing down intended use in "Guidelines for writing
Kconfig files", not just the language specification, makes the document
so much more useful.