[tbot] [PATCH] tbot: Provide login_delay parameter for Linux board

[Stefano Babic]

Hi Heiko,

On 06/03/19 08:16, Heiko Schocher wrote:
> Hello Stefano,
> 
> Am 05.03.2019 um 11:16 schrieb Stefano Babic:
>> Hallo Harald,
>>
>> On 05/03/19 07:29, Harald Seiler wrote:
>>> Hello Lukasz,
>>>
>>> thank you for your patches!  The first one is perfect, I'll apply it
>>> asap.
>>> With the second one I'm not quite happy:  I tried to keep the use of
>>> timeouts
>>> to an absolute minimum in tbot to A) make it as fast as possible and
>>> B) as
>>> robust as possible.  Timeouts introduce unnecessary delays and can
>>> break easily
>>> if they were not set with enough tolerance (which makes things very
>>> sloow).
>>
>> Well, they should just be configurable and skipped if not required.
>>
>>>
>>> Now I am completely aware of the issue you try to solve here as I
>>> have fought
>>> this exact problem myself in the past.  My current best bet for a
>>> solution would
>>> be calling `sysctl kernel.printk 1 1 1 1` at the start of each board
>>> session to
>>> at least keep the kernel from clobbering the console.
>>
>>
>> This is not a generic solution - it changes the product and it is a fix
>> just in case output is coming from kernel. There are a lot of cases
>> where customer's application is just printing to the console at the
>> start up. A delay lets us to configure it on project basis, and dropping
>> kernel output does not help.
> 
> Hmm... I do not like delays ... in my old version of tbot this caused
> just trouble ...
> 

Anyway, this is just for the few cases where the DUT sends garbage to
the console at the start up. We cannot fix if a device goes on to print
to the console because we do not know what it is sending. On most
boards, delay is 0.

> If the output is on every boot the same, may we make it possible to
> configure a string/regular expression we expect, before loging in ?

I do not think so - if the output is coming from an application, the
output is very specific and can change from build to build. It becomes a
mess and it does not work.

> 
> If you have random output on your hardware this will make it not easy
> to test...
> 

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================