[flashrom] [PATCH] Make the laptop warning less scary if unsure

[Carl-Daniel Hailfinger]

Am 25.08.2011 16:16 schrieb Stefan Tauner:
> On Thu, 25 Aug 2011 14:56:56 +0200
> Idwer Vollering <vidwer at gmail.com> wrote
>> 2011/8/20 Stefan Tauner <stefan.tauner at student.tuwien.ac.at>:
>>     
>>> Telling the user to use "force_I_want_a_brick" if it is not even a
>>> laptop, is a bit over-the-top. Introduce a new laptop parameter
>>> "this_is_not_a_laptop" that allows to force operation, but only if
>>> the detection is not sure.
>>>
>>> ---
>>>
>>> complicates the whole thing a bit. could do without the extra
>>> variable and new part of the if condition, if we allow the
>>> this_is_not_a_laptop parameter to always work, not only if the
>>> laptop detection is uncertain. it will be undocumented and only
>>> visible to the user together with the warning anyway...
>>>       
>> I was curious whether the currently present overriding parameter works
>> in combination with the parameter in this patch, and it does: $ sudo
>> ./flashrom -V -p internal:laptop=force_I_want_a_brick -p
>> internal:laptop=this_is_not_a_laptop
>> flashrom v0.9.4-r1418 on FreeBSD 9.0-BETA1 (i386), built with libpci
>> 3.1.7, GCC 4.2.2 20070831 prerelease [FreeBSD], little endian
>> (etcetera)
>>
>> Do you think this behaviour is desired?
>>     

Thanks for spotting this bug, Idwer.


> the force_I_want_a_brick will override the other one (which is then
> neither used nor checked). i think that is ok... this is already way
> too sophisticated imho. :) but thanks for pointing it out, i have not
> thought about it yet. do you think this is a problem?
>   

Yes. There are actually two issues:

- I want to change flashrom to refuse doing any action if a user
specifies --force unnecessarily, and abort if any programmer parameters
are unevaluated after programmer init. Allowing the user to specify
conflicting options for the same parameter is something which will
easily cause pretty explosions.

- AFAICS the second -p internal:... causes the first -p internal to be
ignored completely. That is a bug. In fact, you can even do other fun
stuff like -p internal -p dummy at the same time. That one needs to be
fixed. We could accept multiple -p something for the same programmer in
case people want to specify multiple parameters for a given programmer
(-p dummy:emulate=SST25VF032B -p dummy:image=dummy_simulator.rom), but
we have to combine the parameters internally.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/