On Monday 23 April 2012 17:17:57 Wolfgang Denk wrote:
Mike Frysinger wrote:
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%.
Correct. But then U-Boot is the only master of the CPU, and nothing else can be run in parallel.
In the sandbox, U-Boot is an ordinary user space application and as such is supposed to behave well. Burning 100% CPU is a polling input loop is about the most stupid thing we can do.
not when you're aiming to act like the hardware whenever possible. we specifically do not want #ifdef CONFIG_SANDBOX outside of sandbox-specific drivers if we can avoid it. that means we are bound by the implicit constraints at the driver boundaries. so if u-boot common code does: while (tstc()) ... then sandbox should be eating the cpu. however, it seems that the hush shell does while (getc()), so that shouldn't be an issue here.
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.
Than this needs to be fixed for sandbox?
the only way to fix it is what i suggested: rename "int errno" in lib/errno.c to something like "int uboot_errno" and then add to errno.h: "#define errno uboot_errno". this shouldn't make any difference at all to compiled code. the only difference is that people doing symbol debugging would get a different symbol name. -mike