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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot