[U-Boot] Sandbox question

[Wolfgang Denk <wd@denx.de>]

Dear Mike Frysinger,

In message <201204231657.18531.vapier@gentoo.org> you wrote:
>
> > That's why I wrote "or rather from fd 0".
>
> reading directly from fd 0 makes no difference.  stdin is stdin.  if stdin is 

stdin is stdin (a FILE pointer which uses all the automatic buffering
from stdio), and fd 0 is fd 0 (a plain file descriptoor you can use as
you like).

> backed by a tty, you need to behave differently than if it's backed by a pipe.

This does not play any role in this context, or does it?

> > That's why I suggested to use select() or poll() to poll for available
> > characters, just like the hardware does.  Only we do NOT want to tun
> > this in a tight loop.  We will most likely want to add a sufficiently
> > large delay to keep CPU load in reasonable bounds.
>
> where exactly do you propose adding this delay ?  tstc() is called in many
> places (not just the main console loop), many of which are done simply to 
> handle the unlikely CTRL+C interrupt.  thus we don't want tstc() delaying at 
> all or it'll slow down random CPU-bound operations.

It makes _zero_ sense to burn 100% CPU with this code.  Adding a few
10 ... a few 100 us delay tstc() will probably not be noticed.

Did you try that out?

> also, what you're proposing is changing the behavior of u-boot when it's in
> the sandbox so that it acts less like the hardware.  when you run u-boot on
> the hardware and it's sitting at the prompt, u-boot is running the cpu at 
> 100%.

Correct.  But then U-Boot is the only master of the CPU, and nothing
else can be run in parallel.

In the sandbox, U-Boot is an ordinary user space application and as
such is supposed to behave well.  Burning 100% CPU is a polling input
loop is about the most stupid thing we can do.

> > Why invent new methods when we can encapsulate this in the input
> > interface?
>
> i'm not inventing new methods.  i'm telling you that the sandbox OS layer 
> today cannot access the C library's errno because u-boot's own implementation 
> of errno is overriding it.  so any call sandbox makes to the OS (like read() 
> or select() or poll()) that results in an error, sandbox has no way of knowing 
> the underlying reason.

Than this needs to be fixed for sandbox?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a train station is a place where a train stops,
                                           then what's a workstation?