Dear Mike Frysinger,
In message 201204231503.08835.vapier@gentoo.org you 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".
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?
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.
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?
We do not even have to pass EOF on to higher layers in U-Boot - we could exit directly in the tty interface code.
Best regards,
Wolfgang Denk