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