Re: L4Re: Input via UART fails with Ned involvement

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
>> [email protected]
>> https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 
> 
> _______________________________________________
> l4-hackers mailing list
> [email protected]
> https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

-- 
[email protected] - Tel. 0351-41 883 221
http://www.kernkonzept.com

Kernkonzept GmbH.  Sitz: Dresden.  Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth

_______________________________________________
l4-hackers mailing list
[email protected]
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers