On Tuesday, 19 September 2023 14:34:42 CEST Philipp Eppelt wrote:
>
> I was a tad to quick on the send button. I have to correct myself.
No problem! I appreciated both replies.
> 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'}.
OK. This makes sense. I previously modified the ned.lua file to allow the log
capability to be specified in certain cases, allowing programs to display
their output in a graphical terminal (fbterminal), for example. It occurs to
me now that I didn't need to make this modification: I previously thought that
the log item was only there to specify format parameters.
> 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).
>From the behaviour, I had assumed that a program started directly by moe would
get the same log interface as the one used by the kernel. The clue was in the
way the kernel debugger could be invoked using Escape with the -serial_esc
option and then used, suggesting that the reception of data over the UART was
not broken. Indeed, I think that omitting the -serial_esc option seems to
prevent input from working.
As far as whether passing the log to the application is productive, it might
be adequate in the specific situation I am dealing with, which is to provide
some interaction with a single-board computer over a UART connection.
> 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.
Right. I had suspected that some kind of write-only log had been introduced.
> 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.
I do have some idea of the architectural details, having looked into the C
library support in the past, but I do not find it particularly straightforward
to track down the exact places where the generic C library support meets the
L4Re abstractions.
I imagine that there would have to be some kind of process hierarchy and
perhaps some multiplexing to be introduced to manage kernel log access amongst
user-level applications. In my own experiments, one of the next things I plan
to do is to provide standard input and output streams to processes via pipes,
which follows on from my investigations into creating and invoking tasks. I
suppose that such facilities are beyond the scope of the C library support in
L4Re, however.
Providing L4.Env.log to my application does indeed allow interactive
communication over the UART, so this simple adjustment fixed my immediate
problem. Thank you for your guidance on this matter!
Regards,
Paul
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
