[U-Boot] Sandbox question

[Mike Frysinger <vapier@gentoo.org>]

On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > I don't see why we cannot simply read from stdin (or rathr from file
> > > descriptor 0) as usual?
> > 
> > the "usual" method of reading from stdin involves the tty doing buffering
> > and the application only seeing fully flushed lines.  thus it would not
> > operate the
> 
> That's why I wrote "or rather from fd 0".

reading directly from fd 0 makes no difference.  stdin is stdin.  if stdin is 
backed by a tty, you need to behave differently than if it's backed by a pipe.

> > same as the hardware (where u-boot gets every char as you type) and you
> > wouldn't be able to handle things like tab completion.
> 
> C'me on.  That's a standard issue.  We know how to handle this, right?

and it's being handled already in the code because i submitted a patch to do 
so.  my point was that sandbox can't read from stdin "as usual".

> > > You can use standard methods like select() or poll() to wait for input,
> > > which will also inform you about events like EOF.
> > 
> > because that isn't how u-boot on the hardware works.  u-boot itself calls
> > tstc() to see if there's any data and does so in a continuous loop.  when
> > there is data, it calls getc().  tstc() should not block, and getc()
> > isn't call unless u-boot knows there's data.
> 
> 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.

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%.

> > it is also problematic (currently) to get access to errno from the C
> > library because u-boot itself has a variable called "errno".  so we
> > cannot call the C
> 
> 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.

> We do not even have to pass EOF on to higher layers in U-Boot - we
> could exit directly in the tty interface code.

yes, we can special case the sandbox-specific serial driver and have it call 
the sandbox-specific exit function when EOF is reached.

if it's a pipe, we can do it in the tstc() func by waiting until POLLIN is 
cleared and POLLHUP is set.

if it's a tty, the eof key (CTRL+D by default) will emit an EOT byte (0x04) 
which we will read in getc().  that is, if we want to actually support this.  
after all, doing CTRL+D on a serial port won't cause the board to reset, so 
i'm not sure the sandbox shell should exit either.  plus, this would get in 
the way of code reading arbitrary data.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120423/e7ce5e8d/attachment.pgp>