Hello,
I have a few sandbox related questions (examples run on v2012.04)
1) Memory map - What is it supposed to look like?
I get "DRAM: 128 MiB", and
=>bdi boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
Yet I get:
=>md 0x100 00000100:Segmentation fault
2) Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work:
$ echo printenv | ./u-boot
[As woraround I have to use ``echo 'printenv;reset' | ./u-boot''; this works, but is not really intuitive nore useful.]
3) For automatic test suites it would make a lot of sense if the return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin).
What do you think?
Best regards,
Wolfgang Denk
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
=>md 0x10000000100:Segmentation fault
yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right.
Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work:
$ echo printenv | ./u-boot
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.
- For automatic test suites it would make a lot of sense if the return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin).
i'm not sure how hard that is to pass on. Simon might know since he's been grubbing around the shell internals lately. we could have reset take an argument in the sandbox path so it's easy to pass back arbitrary values in the middle of a script. -mike
Am 23.04.2012 17:41, schrieb Mike Frysinger:
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
=>md 0x10000000100:Segmentation fault
yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right.
I suggested another solution: http://patchwork.ozlabs.org/patch/123074/
This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned.
This could be caught by an assert. The base address in the patch (0x20000000) was choosen with respect to the typical process address layout on x86 and x86_64 linux to avoid any conflict. Even when ASLR causes this the u-boot binary could still be started using setarch with ASLR disabled.
Dear Matthias Weisser,
In message 4F959235.1070106@arcor.de you wrote:
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
=>md 0x10000000100:Segmentation fault
yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right.
The PPC code just accesses physical memory, as is.
I suggested another solution: http://patchwork.ozlabs.org/patch/123074/
This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned.
I don't see why this would be needed.
I think you got things backwards.
Please note that I do NOT complain that "md 0x100" or "md 0" segfaults in general; it is IMO perfectoy OK to do this if there is no memory. But the "bdinfo" command reported that memory starts at 0, and then both these commands are supposed to work.
I am not asking for any specific mapping - I just ask for _consistent_ information provided to the user.
Best regards,
Wolfgang Denk
Am 23.04.2012 19:39, schrieb Wolfgang Denk:
I suggested another solution: http://patchwork.ozlabs.org/patch/123074/
This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned.
I don't see why this would be needed.
Because you will have the same address for "physical memory" in all instances of sandbox u-boot. This could simplify test scripts a bit. Imagine testing tftp downloads to memory where DRAM bank-> start is different for every program run. This was a PITA for me while testing the tap ethernet simulation for sandbox. And that is why I came up with the patch.
Or is there something like $(ramstart) in u-boot?
Dear Matthias,
In message 4F959612.7040903@arcor.de you wrote:
Because you will have the same address for "physical memory" in all instances of sandbox u-boot. This could simplify test scripts a bit. Imagine testing tftp downloads to memory where DRAM bank-> start is different for every program run. This was a PITA for me while testing the tap ethernet simulation for sandbox. And that is why I came up with the patch.
Agreed - though I would expect the mapping at least to be consistent through all runs of the same binary image.
Or is there something like $(ramstart) in u-boot?
Not yet - but it would be trivial to add.
Best regards,
Wolfgang Denk
Am 23.04.2012 20:30, schrieb Wolfgang Denk:
Dear Matthias,
In message4F959612.7040903@arcor.de you wrote:
Because you will have the same address for "physical memory" in all instances of sandbox u-boot. This could simplify test scripts a bit. Imagine testing tftp downloads to memory where DRAM bank-> start is different for every program run. This was a PITA for me while testing the tap ethernet simulation for sandbox. And that is why I came up with the patch.
Agreed - though I would expect the mapping at least to be consistent through all runs of the same binary image.
This would be the case as long as the u-boot image is run without ASLR which can be achieved by running it using setarch
Or is there something like $(ramstart) in u-boot?
Not yet - but it would be trivial to add.
And would fix the issue without any problems introduced by hinted mmap or an "address translation layer". But ramstart would be different on every run of the binary if ASLR is active.
Hi Wolfgang,
On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
=>md 0x100 00000100:Segmentation fault
yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right.
The commit which made this work was this one:
355a835 sandbox: Change md command to use map_physmem
and was reverted by:
94c50f1 Revert "sandbox: Change md command to use map_physmem"
The commit message from the revert is
The original commit broke long standing assumption that md commands work on effective addresses. This normally isn't an issue for most systems that map 1:1, however on systems with a 36-bit address map it breaks.
I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op.
I am pretty keen for sandbox memory to start at 0 if possible, since it makes test code easier to write if we can make that assumption. Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config.
- Sandbox does no handle EOF on stadin; this makes it impossible to
use it in test scripts. For example, something like this should work:
$ echo printenv | ./u-boot
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 which accepts EOF on input and somehow passes it up the stack, or keeps the info in sandbox's state. Another option would be to create a special sandbox input device. In any case, it would be nice to implement EOF in the console layer for this. Could be related to serial cleanup also.
- For automatic test suites it would make a lot of sense if the
return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin).
i'm not sure how hard that is to pass on. Simon might know since he's been grubbing around the shell internals lately. we could have reset take an argument in the sandbox path so it's easy to pass back arbitrary values in the middle of a script.
I'm pretty sure I had this working, at least for one shell. It was part of the motivation for the command cleanup.
It would be worth sorting out these three things. Once we have a bit of agreement on which way to go, I'm happy to come up with some patches for any that don't have volunteers.
-mike
Regards, Simon
Dear Simon,
In message CAPnjgZ1aV723LzF1vnMOArix6DNXFHO-962Y8WQij5-G46226g@mail.gmail.com you wrote:
I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op.
I don't see why such a function would be needed. Other architectures don't need it either. Yes, some architectures use a common, fixed mapping (like PPC, where physical RAM almost always starts at address 0x0) - but others don't have such a common map- for example on ARM, there is a wild mix where RAM starts, and basicly every SoC defines his own mapping.
I am pretty keen for sandbox memory to start at 0 if possible, since it makes test code easier to write if we can make that assumption.
On ARM you don't have this either.
Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config.
Eventually introducing two variables like ramstart and ramend would solve 90% of the potential issues.
In any case, information returned by commands like bdinfo must be correct.
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? You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF.
which accepts EOF on input and somehow passes it up the stack, or keeps the info in sandbox's state. Another option would be to create a special sandbox input device. In any case, it would be nice to implement EOF in the console layer for this. Could be related to serial cleanup also.
Good point.
Marek, can you please add this to the DM planning?
It would be worth sorting out these three things. Once we have a bit of agreement on which way to go, I'm happy to come up with some patches for any that don't have volunteers.
Thanks!
Best regards,
Wolfgang Denk
On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote:
Simon wrote:
I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op.
I don't see why such a function would be needed. Other architectures don't need it either. Yes, some architectures use a common, fixed mapping (like PPC, where physical RAM almost always starts at address 0x0) - but others don't have such a common map- for example on ARM, there is a wild mix where RAM starts, and basicly every SoC defines his own mapping.
because, as you said, you want things to be deterministic. when the sandbox starts up, it does mmap() and there's no guarantee that the address you get back is always going to be the same. you cannot compare this to an SoC where the memory layout is always exactly the same for u-boot across runs. thus we need the map call to adjust what the user sees (memory always starts at 0) vs what sandbox got back from the kernel (almost literally, any address).
Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config.
Eventually introducing two variables like ramstart and ramend would solve 90% of the potential issues.
In any case, information returned by commands like bdinfo must be correct.
it was correct. and then the change that made it correct was reverted. -mike
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
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
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
On Monday 23 April 2012 16:57:16 Mike Frysinger wrote:
On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
Mike Frysinger wrote:
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%.
hmm, maybe the hush shell works differently and calls getc() directly rather than itself calling tstc(). so in the hardware, it eats the cpu because the hardware has no way of sleeping for the data, but in an OS we can wait for input. should be easy to post a patch for this code path. -mike
Dear Mike Frysinger,
In message 201204231657.18531.vapier@gentoo.org you wrote:
That's why I wrote "or rather from fd 0".
reading directly from fd 0 makes no difference. stdin is stdin. if stdin is
stdin is stdin (a FILE pointer which uses all the automatic buffering from stdio), and fd 0 is fd 0 (a plain file descriptoor you can use as you like).
backed by a tty, you need to behave differently than if it's backed by a pipe.
This does not play any role in this context, or does it?
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.
It makes _zero_ sense to burn 100% CPU with this code. Adding a few 10 ... a few 100 us delay tstc() will probably not be noticed.
Did you try that out?
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.
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?
Best regards,
Wolfgang Denk
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
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work:
$ echo printenv | ./u-boot
[As woraround I have to use ``echo 'printenv;reset' | ./u-boot''; this works, but is not really intuitive nore useful.]
(raw) patch below handles that. it doesn't handle this though: ./u-boot <<<help but maybe i'm the only one who uses that form -mike
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index 36637af..a579b3c 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -22,6 +22,7 @@ #include <errno.h> #include <fcntl.h> #include <getopt.h> +#include <poll.h> #include <stdlib.h> #include <termios.h> #include <time.h> @@ -253,3 +254,43 @@ int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
return 0; } + +static short os_poll_flags(short flags) +{ + short ret = 0; + if (flags & POLLIN) + ret |= OS_POLLIN; + if (flags & POLLHUP) + ret |= OS_POLLHUP; + return ret; +} + +static short poll_flags(short os_flags) +{ + short ret = 0; + if (os_flags & OS_POLLIN) + ret |= POLLIN; + if (os_flags & OS_POLLHUP) + ret |= POLLHUP; + return ret; +} + +int os_poll(struct os_pollfd *fds, ulong nfds, int timeout) +{ + struct pollfd _fds[nfds]; + int ret; + ulong i; + + for (i = 0; i < nfds; ++i) { + _fds[i].fd = fds[i].fd; + _fds[i].events = poll_flags(fds[i].events); + _fds[i].revents = poll_flags(fds[i].revents); + } + ret = poll(_fds, nfds, timeout); + for (i = 0; i < nfds; ++i) { + fds[i].fd = _fds[i].fd; + fds[i].events = os_poll_flags(_fds[i].events); + fds[i].revents = os_poll_flags(_fds[i].revents); + } + return ret; +} diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c index 1927c16..9d7ef6b 100644 --- a/drivers/serial/sandbox.c +++ b/drivers/serial/sandbox.c @@ -48,16 +48,30 @@ void serial_puts(const char *str) os_write(1, str, strlen(str)); }
+static short serial_tstc_timeout(int timeout) +{ + struct os_pollfd fds = { + .fd = 0, + .events = OS_POLLIN, + }; + + os_poll(&fds, 1, timeout); + return fds.revents; +} + int serial_getc(void) { char buf; - ssize_t count; + short flags; + + flags = serial_tstc_timeout(1); + if (!(flags & OS_POLLIN) && (flags & OS_POLLHUP)) + os_exit(0);
- count = os_read(0, &buf, 1); - return count == 1 ? buf : 0; + return os_read(0, &buf, 1) == 1 ? buf : 0; }
int serial_tstc(void) { - return 0; + return !!(serial_tstc_timeout(0) & OS_POLLIN); } diff --git a/include/os.h b/include/os.h index 699682a..bc9fde2 100644 --- a/include/os.h +++ b/include/os.h @@ -136,4 +136,15 @@ u64 os_get_nsec(void); */ int os_parse_args(struct sandbox_state *state, int argc, char *argv[]);
+struct os_pollfd { + int fd; + short events; + short revents; +}; + +#define OS_POLLIN 0x01 +#define OS_POLLHUP 0x10 + +int os_poll(struct os_pollfd *fds, ulong nfds, int timeout); + #endif
Dear Mike Frysinger,
In message 201204231751.24880.vapier@gentoo.org you wrote:
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work:
$ echo printenv | ./u-boot
[As woraround I have to use ``echo 'printenv;reset' | ./u-boot''; this works, but is not really intuitive nore useful.]
(raw) patch below handles that. it doesn't handle this though: ./u-boot <<<help but maybe i'm the only one who uses that form -mike
Do you intend to submit this as a proper patch?
Best regards,
Wolfgang Denk
On Thursday 09 August 2012 16:39:20 Wolfgang Denk wrote:
Mike Frysinger wrote:
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote:
Sandbox does no handle EOF on stadin; this makes it impossible to
use it in test scripts. For example, something like this should
work: $ echo printenv | ./u-boot
[As woraround I have to use ``echo 'printenv;reset' | ./u-boot''; this works, but is not really intuitive nore useful.]
(raw) patch below handles that. it doesn't handle this though: ./u-boot <<<help
but maybe i'm the only one who uses that form -mike
Do you intend to submit this as a proper patch?
it was meant as an RFC. no one was unhappy with it, so i'll clean it up and submit like normal. -mike
participants (5)
-
Matthias Weisser -
Matthias Weißer
-
Mike Frysinger -
Simon Glass -
Wolfgang Denk