Re: [PATCH 5/6] kconfig: implement KCONFIG_PROBABILITY for randconfig

[Michal Marek <mmarek@suse.cz>]

Dne 23.4.2013 18:34, Yann E. MORIN napsal(a):
> Michal, All,
> 
> On Tue, Apr 23, 2013 at 10:44:58AM +0200, Michal Marek wrote:
>> On 22.4.2013 23:31, Yann E. MORIN wrote:
>>> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
>>> index 13ddf11..8d8d853 100644
>>> --- a/scripts/kconfig/confdata.c
>>> +++ b/scripts/kconfig/confdata.c
>>> @@ -1106,7 +1106,16 @@ static void set_all_choice_values(struct symbol *csym)
>>>  void conf_set_all_new_symbols(enum conf_def_mode mode)
>>>  {
>>>  	struct symbol *sym, *csym;
>>> -	int i, cnt;
>>> +	int i, cnt, prob = 50;
>>> +
>> [...]
>>>  			case def_random:
>>> -				cnt = sym_get_type(sym) == S_TRISTATE ? 3 : 2;
>>> -				sym->def[S_DEF_USER].tri = (tristate)(rand() % cnt);
>>> +				cnt = (rand() % 100) - (100 - prob);
>>> +				if (cnt < 0)
>>> +					sym->def[S_DEF_USER].tri = no;
>>> +				else
>>> +					if ((sym_get_type(sym) == S_TRISTATE)
>>> +					    && (cnt > prob/2))
>>> +						sym->def[S_DEF_USER].tri = mod;
>>> +					else
>>> +						sym->def[S_DEF_USER].tri = yes;
>>
>> Previously, the distribution was 50%-50% for boolean options and
>> 33%-33%-33% for tristate options. Now the default for tristate options
>> changed to 50%-25%-25% (no-mod-yes). Wouldn't it make more sense to have
>> a special case for KCONFIG_PROBABILITY not set, that would use the same
>> distribution as before. I.e.
>>
>> if (prob == -1) {
>> 	cnt = sym_get_type(sym) == S_TRISTATE ? 3 : 2;
>> 	sym->def[S_DEF_USER].tri = (tristate)(rand() % cnt);
>> } else {
>> 	/* new math */
>> }
> 
> OK, what about this proposal, instead:
>     KCONFIG_PROBABILITY     y:n split           y:m:n split             Notes
>     -------------------------------------------------------------------------
>     unset or empty          50  : 50            33  : 33  : 34          [1]
>     N                        N  : 100-N         N/2 : N/2 : 100-N       [2]
>     N:M                     N+M : 100-(N+M)      N  :  M  : 100-(N+M)   [3]
>     N:M:L                    N  : 100-N          M  :  L  : 100-(M+L)   [4]
> 
> [1] current behaviour
> [2] the curent patch's behaviour
> [3] boolean's Y probability is tristate's Y plus tristate's M probabilities
> [4] all probabilities explicitly stated
> 
> I have a prototype for this I need to clean up. If that's OK for you, I'll
> submit that; if not, I'll use your suggestion.

As long as the default behavior does not change (1/3 vs. 34% is fine
:)), then I am fine with any semantics of $KCONFIG_PROBABILITY.

Michal