OSDev.org

How does one identify the Operating System abstractions an application / library requires?

Specifically, I'm trying to understand the actual OS abstractions that ROS 2 (Robot Operating System) applications requires from the actual Operating System it runs on top of; however, I'm not entirely sure where to begin. For those who aren't familiar with ROS, it is a meta-OS that creates executable binaries that run on Ubuntu-based Linux distros by default.

As a purely education exercise, I'm trying to evaluate whether it would be possible to port ROS 2 to a currently unsupported OS.

However, as a starting point, I thought it would be a good idea to identify the actual OS abstractions a typical ROS application needs; however, I'm unsure how to approach this challenge.

Should I look through all the C libraries ROS 2 uses to examine headers and system calls that the ROS 2 client library (a C library) uses? Should I run `strace` on a ROS 2 executable to see what system calls it makes? I have ideas but I'm not sure if they're the right ones!

This is my first time attempting to port anything to a new OS so I was wondering if any people with experience can potentially share some advice on how they would start a project like this and where to start looking?

Thanks!

I like some of the answers you got on reddit, particularly about looking at dependencies, though an important amendment to what Qweesdy said is that those dependencies may not be requirements - OpenCV, for example, can be built without any GPU dependencies (it'll be very slow doing all of its work in software, but it's capable of it!).

Your thought of using strace I don't think will get you too far. strace tells you about system calls, but system calls won't tell you very much about what an application needs when it's hidden away behind generic interfaces like device files and sockets. Looking at libraries is far more important, especially if your aim is to answer the question of what your OS needs to port something.

ldd lists the libraries a program is dynamically linked with. It won't show libraries loaded at runtime though (with dlopen).

What I've been doing for porting software is to just try to build and run it.

While building, I expect a ton of missing includes. Then I try to figure out: is it an optional dependency that I can disable, or do I need to find what package it belongs to and port that too?

My next step is to try to run it. During the process of porting musl, I stubbed out all of the Linux system calls to print unimplemented messages with the system call that's unimplemented. Then I see what the program complains is unimplemented, and I implement a shim to emulate the behavior of the system call (and leave a message for unhandled flags.)

These stages are how I installed out-of-distro stuff on Linux in the 00s, especially on LFS in '02 and Slackware later. Sometimes it went smoothly, especially near the beginning of the decade when most things were just written in C with relatively few libraries. Later, it was common to find one dependency with a long list of other dependencies, and some of those would have long lists of dependencies too. All too often, a simple program would pull in several far more complex unrelated packages via its dependencies. I suppose it might be all right if you have the patience to just put off your goal for days or even weeks, but I got tired of even looking for interesting new software at all! lol

The difference between a software written for portability as opposed to software written with a specific infrastructure (e.g. Linux) in mind. There is nothing wrong with software that expects "all the usual stuff" present in your average Linux distro, just as there is nothing wrong with software that expects WinAPI, DirectX et al. -- they just aren't "portable", as that usually means "keeping your dependencies at a minimum". Something that has increasingly fallen out of favor, especially since compatibility layers like Wine or Cygwin make it so easy to run "the other half of the software".

Interesting! Especially that depending on a specific infrastructure is falling out of favour. My problem was that I always ran a fairly minimal Linux system, a lot of "the usual stuff" just wasn't there. I didn't want to change that for various reasons, good and bad. Using Windows eliminates the problem; if I see something interesting but it doesn't have a Windows port, I just don't consider trying it.