I tried adding new commands to the provided terminal, and it was successful in cases where there were no system dependencies. However, the issue I’m facing is how to use programs that rely on system services, like ping or similar.
Is there any sample code or example available for this?
I, too, tend to look for blue-prints and examples as a source of inspiration for such changes.
Genodians articles such as this one tend to help in my case, for hand-crafted XML configuration. Or this if you’re generating the XML from C++. I also keep tabs on how to configure Sculpt OS recipes and runtimes, as that can also be easily extrapolated to ‘raw’ XML configurations: one, two
YMMV (your mileage may vary) ^^
I have added two types of programs to the terminal:
First Program:
int main(int argc, char *argv[])
{
printf("------------ %s", argc <= 1 ? argv[0] : argv[2]);
}
Second Program:
void Libc::Component::construct(Libc::Env &env)
{
Libc::with_libc([&] {
Genode::log("------------", &env);
env.parent().exit(0);
});
}
Both programs were placed in the bin folder and added to the terminal using the tar command provided in the XML structure. The first program produced the expected output. However, the second program encounters the following error:
[init -> /bin/bash -> 1] Error: LD: Non-RW/RX segment
[init -> /bin/bash -> 1] Error: Uncaught exception of type 'Linker::Invalid_file'
[init -> /bin/bash -> 1] Warning: abort called - thread: ep
The second code is a simple example to enable me to utilize all available tools in Genode.
The fork / execve mechanism used by bash can currently only start POSIX programs.
Makes sense – also a couple observations for hamed:
with_libc(), not the other one 
and even then, not in all cases, I think it’s only when mixing and matching POSIX code and Genode code (signal handlers etc) in the same thread – there’s still a lot I need to understand about with_libc() so do dig in that directionIs there really no way? Is there no possibility of using RPC either? If RPC can be used, please guide me.
For example, I would like to be able to run the ping program in a non-POSIX environment and receive its results using RPC, then display the output.
Seems to me if you really, really need your program to be launched from a command-line terminal or a bash script, then you’ll have to modify your program to have a main() function (which as noted, does not limit you in any way, it can still use Genode RPC and anything Genode has to offer: that’s how ports are made, like Falkon: Falkon is a posix app that uses the Qt library, which itself uses many Genode APIs).
Even so, you might still want to also look into init, since that’s the native way of launching programs in Genode. (or to be more accurate, it’s a nice and convenient xml-piloted wrapper component on top of the Genode “child” API).
As to the native ping utility,
IIRC it outputs its results with Genode::log(), i.e. textual output to the LOG service. But its return code might be usable from the outside though, didn’t check.
The preferred way for POSIX programs to interact with non-POSIX components is via VFS plugins. For example, you could have a POSIX ping wrapper program or shell script which writes an XML init configuration for the non-POSIX ping component to a file which is read as ROM by an init component which then starts the ping component. The log output of the ping component could then be redirected to a named pipe file which is read by the ping wrapper POSIX program using the pipe VFS plugin. Just an untested idea.
Qt mainly uses VFS plugins like lwip or lxip for the network connection, or the oss VFS plugin for audio, but it also interacts with the Gui session directly. A problem with direct session use in POSIX programs is how to obtain the Genode::Env object which is needed for that. Qt applications use a special variant of the posix library named qt5_component, which passes this object to Qt before calling the main() function. The fork / execve mechanism assumes that posix.lib.so is used, so I think it would not be possible to start Qt applications directly from bash either.
Interesting, didn’t know that! That would likely also apply in my h/o/g library’s case: I don’t use posix.lib.so but re-implement its functionality in haiku.lib.so (to register Env etc), so apps that link against it would not be launchable from a bash terminal then. Never noticed that before because until now I’ve been launching apps only from the GUI (Deskbar).
Might be something to keep on my ‘radar’ in the long term, nothing urgent though.
Thanks! This is exactly the idea that came to my mind too. It seems like this is the only solution, and it works well for a program like ping. But in situations where performance is important, this approach might run into some challenges.
I’ll probably try to write a suitable wrapper, similar to qt5_component, that can retrieve the env variable and add RPC to the setup as well. I also hope to leverage the experiences of others from different branches.
Thanks again for your explanation. It confirmed that I’ve understood the key concepts of the Genode framework quite well, which I’m really glad about.
May I ask, why you are sticking to the UNIX shell? All other components of Sculpt OS are managed by native Genode services.
I have reviewed Sculpt OS, and one of the serious shortcomings I noticed is the inability to easily add common system applications, such as network tools, to the OS. One major advantage of the Genode framework, however, is the ability to test and run a Linux kernel, which greatly simplifies development. I believe that if the framework supported common cross-platform applications, it would attract a significant number of developers. This would, in turn, transform it from being a specialized or educational OS into a mainstream operating system for embedded systems.
To that end, I first tried to familiarize myself with the concepts of the Genode framework. Adding a kiosk application to the system and working with dynamic configurations helped clarify these concepts to a good extent. However, I believe there are still some areas that need further discussion, which I plan to address in separate topics.
To deepen my understanding of Genode’s modular structure, I attempted to integrate POSIX-like programs into the UNIX shell. This was done to explore how a fully POSIX-compliant structure interacts with the Genode framework.
Thanks for the clarification.
From my experience, the mentioned network tools (nmap, hping3, tshark, etc.) heavily depend on operating-system interfaces for some kind of raw socket to craft special network packets and monitor all traffic. In addition other OS-specific features like /proc, /sys, or netlink sockets may be used to discover/adjust network configurations. Therefore, the success of porting standard tools rises and falls with the implementation of these non-standard interfaces in our POSIX runtime (best as VFS plugins like @cproc metioned).