Graphical Log Capturing

I am attempting to capture program logs in a manner similar to Sculpt OS. From my understanding, the terminal_log service is designed for this purpose. However, I’m encountering issues where neither the testing of this service functions as expected, nor does the transfer of Sculpt OS settings to applications like tiled_wm work correctly. My goal is to retrieve logs within the tiled_wm example, specifically in the overlay section.

I believe that the following two modules are essential for displaying the logs:

<start name="log_terminal" priority="-1">
    <binary name="file_terminal"/>
    <resource name="RAM" quantum="2M"/>
    <provides> <service name="Terminal"/> </provides>
    <config>
        <default-policy filename="log" />
        <vfs> <dir name="dev"> <log/> </dir> <fs/> </vfs>
        <libc stdout="/dev/log"/>
    </config>
    <route>
        <service name="File_system"> <child name="report_fs"/> </service>
        <any-service> <parent/> </any-service>
    </route>
</start>

<start name="log" priority="-1">
    <binary name="terminal_log"/>
    <resource name="RAM" quantum="1M"/>
    <provides> <service name="LOG"/> </provides>
    <config/>
    <route>
        <service name="Terminal"> <child name="log_terminal"/> </service>
        <any-service> <parent/> </any-service>
    </route>
</start>

I have added the log module to the XML structure intended for the window_layouter, expecting to see it reflected in the overlay section. However, it appears that there are serious shortcomings. I also hope that the log structure in Sculpt OS is not intertwined with the structure of leitzentrale.

I have the feeling, it may be most helpful if you would share those shortcomings to get any help for clearing any obstacles.

1 Like

When I execute this transferred structure, I don’t encounter any errors or outputs that might give me hints to pursue further or share with you. Because of this, I was hoping you could provide some assistance.

My understanding was that initially, there needs to be a component that receives the logs, which is the responsibility of terminal_log, and another component to display them, handled by file_terminal. Therefore, I expected to achieve graphical log display simply by adding these two components.

The terminal_log and log that you pasted are from sculpt.run. These components are actually responsible for providing a LOG service and writing the data to the /report/log file. You see this by looking at the services they provide and their routes. The log component provides the LOG service and its required Terminal service is routed to terminal_log. The latter, on the other hand, provides a Terminal service and its required File_system service is routed to report_fs.

In repos/gems/sculpt/leitzentrale/default (which becomes /config/leitzentrale on Sculpt), you actually find two similarly named components. These are the components you are looking for because they take care of graphically displaying the /report/log.

1 Like

I use another technique in my Genode-based system, where the terminal_log is connected to a log_terminal and then connected to an on-screen Terminal window (as seen at the top of this ticket), that is, there is no writing to an interim file involved as seen in SculptOS. But I’ve been meaning to look for an alternative, e.g. from the way SculptOS does it. I don’t have enough of a grasp on the whole thing to understand what the pros and cons of each technique are. I do know my technique requires all ‘clients’ to explicitely route their LOG output to my log_terminal, which is a little annoying, whereas it seems SculptOS does not have that problem.

But I can post some system composition code if that’d help you though, limited as it is.

Instead of using the “file_terminal”, use the “terminal” component, which requires a “GUI” session to display the content, an excerpt from a working run scenario (repos/libports/run/acpi_suspend.run):

<start name="terminal_log" caps="100">
	<resource name="RAM" quantum="1M"/>
	<provides> <service name="LOG"/> </provides>
	<config/>
	<route>
		<service name="Terminal"> <child name="terminal"/> </service>
		<any-service> <parent/> </any-service>
	</route>
</start>
<start name="terminal" caps="110">
	<resource name="RAM" quantum="6M"/>
	<provides><service name="Terminal"/></provides>
	<config>
		<initial width="1200" height="780"/>
		<palette>
			<color index="0" value="#2f3953"/>
			<color index="8" value="#2f3953"/>
		</palette>
		<vfs>
			<rom name="VeraMono.ttf"/>
			<dir name="fonts">
				<dir name="monospace">
					<ttf name="regular" path="/VeraMono.ttf" size_px="10"/>
				</dir>
			</dir>
		</vfs>
	</config>
	<route>
		<service name="Gui"> <child name="wm"/> </service>
		<any-service> <parent/> <any-child/></any-service>
	</route>
</start>
1 Like

Thank you, this is exactly what I needed. I had suspected that this module was intended for file system usage, but the naming somewhat misled me.