Hi Paul,
I was a tad to quick on the send button. I have to correct myself.
Moe starts the init task (ned or e.g. hello) and provides the kernel's log interface in Env::Log. When ned starts a program we have to differentiate two cases: A) we explicitly provide a log capability, and B) we do not provide a log capability or we provide arguments of the format {'tag', 'color'}.
The invocations of `start()` I mentioned in my previous email use case A) and provide L4.Env.log, which references the kernel's log interface. (contrary to my last email). Because ned is started as init task and thus gets access to the kernel log interface via this capability. Specifying this again forwards the kernel's log interface to the new application (Nothing to recommend in a productive setup, of course).
In case B) (and assuming L4.default_loader), ned issues a call to moe to create a new log interface for this new application. Thus, all log calls are routed through moe. Now moe's log interface is only able to do output and cannot provide input.
In my understanding, fgets() is implemented to call onto the log capability to read data from it. In case B), reads are not supported and an error is returned which results in the perceived return value of NULL.
So it's actually the other way round than described in my last email.
Cheers, Philipp
On 9/19/23 11:56, Philipp Eppelt wrote:
Hi Paul,
thanks for bringing this up. I can reproduce this on my machine. I don't fully understand the root cause for this behavior quite yet, but I can provide a way to continue.
First, there is a fault in the documentation for the ned-prompt startup, the correct lua line is:
l:start({ log = L4.Env.log, caps = { svr = cmd} }, "rom/ned-prompt")
Contrary to the documentation you linked to, `log` must be declared outside of the `caps` table. With this fix, ned-prompt waits for input.
For the hello startup the same fix applies. Explicitly specifying the log capability within the table parameter of the call to `start()` leads to a working input:
L4.default_loader:start({ log = L4.Env.log }, "rom/hello")
The difference between the case with log parameter set to L4.Env.log and without log parameter - so an implicit/default log capability - is that L4.Env.log references Moe to handle the log interactions. Otherwise, the kernel's log is directly used, which seems to behave differently. I don't know why yet.
Cheers, Philipp
On 9/19/23 00:05, Paul Boddie wrote:
Hello,
I have been trying to get some sensible behaviour from various programs running in L4Re that wish to read from standard input, hopefully using the UART, since standard output is successfully sent across the serial connection. However, it appears that Ned does something rather undesirable with the input stream.
If I modify the hello example to use fgets and deploy it without Ned (the hello.cfg example in conf/examples), as long as some kind of serial initialisation has occurred, I can enter characters at the serial console and have the program read them. However, if I deploy the same code using Ned (the hello.cfg example in conf/examples), fgets repeatedly returns NULL.
Strangely, if I follow the instructions in the L4Re documentation...
https://l4re.org/doc/l4re_servers_ned.html#l4re_ned_interactive
The ned-prompt program itself just prints "Cmd>" over and over again, failing to read anything. It is as if non-blocking I/O has been enabled, although ned- prompt appears to use readline, so I imagine that there is likely to be a somewhat different explanation. Attempting to enforce non-blocking input using fcntl in the hello example also does not help.
Has anyone any suggestions as to why these things do not work? I have tried this on physical hardware as well as in QEMU.
Thanks in advance,
Paul
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers