[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote:
> Simon wrote:
> > > currently as designed -- this is how the hardware works after all.  it
> > > keeps polling stdin forever and there is no concept of "EOF" in a
> > > serial port.  the reads are also non-blocking, so i'm not sure it's
> > > possible to tell when you've got EOF vs read too fast.  might be able
> > > to contingent on stdin being a TTY though.
> > 
> > Yes I think this captures the current situation. We could perhaps add
> > some sort of hack to make this work, perhaps with a new CONFIG option
> 
> 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 
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.

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

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 
library's read() and check errno to see why it failed.  would be possible to 
solve by having u-boot internally rename the storage from "errno" to something 
else, and then having u-boot's errno.h header define "errno" to the rename 
value.
-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/cb422b05/attachment.pgp>