[Q] Kernel free mode?

[lars18th]

Hi @lelegard ,

A lot of times we have discussed about a static/portable mode of the TSDuck. And you've explained very well why we can't have a Linux static portable mode of the tool. However, please let me to reintroduce (another time) the topic. After all, please think that I'm a big fun of Windows Portable tools. So, from my point of view, the best software tool it's the one that can run in any place without changes.

After said that, please can you explain if we can compile a version of TSDuck without any kernel dependency? I understand that to use "tuners", we need to compile with some kernel support. This is mandatory. However, I feel that some other functionalities could be executed without kernel support. Right? Then, in this case it could have sense to compile only part of the TSDuck without kernel headers. You agree with that?

If you're now thinking about why we need this, then consider to run a minimal binary of tsduck without distro dependecies (only the internal required libraries and plugins that could be inside the same directory of tsduck). The objective is a fully portable tsduck that could be run inside a container for task such as pipe processing. If you know how works the busybox tool then I'm sure you could understand the request.

I hope you don't be tired of considering this. My idea with this post it's only to discuss about practical and feasible enhancements. And you another time have a good argument to discard this, then I'll close it. I want to be polite in any case. Regards and thank you for this great tool.

[lelegard]

from my point of view, the best software tool it's the one that can run in any place without changes.

On Linux this is a myth in the general case (regardless of potential simple use cases which may work).

Linus Torvalds himself has publicly regretted that. See: https://www.youtube.com/watch?v=Pzl1B7nB9Kc

So, in the Linux world, I won't go into a direction which is already considered as a dead end by Linus Torvalds.

[lars18th]

Hi @lelegard ,

Perhaps I've explained the request wrong: Personally I prefer the "Linux distro packages" over the user friendly Linux Apps (Snap, for example). I'm not requesting about anything of this. The TSDuck project is for admins/developers and not for users. So this isn't the objective.

Even today we can create and run containers in a lot of different platforms, the construction of such containers require a lot of work. Mainly the work is to build the container with all the tools inside it. And to add a new tool, we have two options: compile it internally or copy the binary from a source. You will perhaps think that compile a tool like TSDuck inside a container is not a problem. And in fact, if you're building a complex container, it's easy. And this is true because your particular support of a lot of different platforms; and your effort to test every release on several distributions. So, nothing to say in this regard, except to say thank you for the good work you are doing. 👍

The problem is when you (we) want: first, that the container doesn't have requirements about the kernel of the host manager. Second, when you want to use some specific tsduck functionality and not the ful environment. For example, you want to use it with pipes to clean a MPEG-TS from a ffmpeg process to provide a DVB conformant stream. In this particular case, the tsp could be sufficient if it can read/write from the stdin-stdout and patch/remove/insert some PSI tables. So, in this case we don't need anything more than a simple binary compiled for the target architecture (and here think not only on x86_64, but for example a mips16 small CPU in one IoT device or FPGA).

I know that this particular use will be far for your work. But the TSDuck tool it's proven very good and robust. So use it in such environments have a lot of sense. Therefore my request is this: Could you add more options to compile it with less dependencies? In particular all related to the kernel and with minimal libraries.

Thank you another time to take the time to read my crazy requests. Regards.

[lelegard]

Requests for such environments are too specific.

The potential problems are more important than the gain. Options to compile without such or such dependency means using #ifdef everywhere and I hate that for many reasons. There are some for good reasons, when there is no other solution than having them (eg. no DTAPI on Mac or Arm Linux, no RIST package on Linux distros). Each time I have to work with those #ifdef, there are always combinations which are not tested and may not compile when a user tries it. It brings many frustrations and complains.

What is the gain for that? A few kilobytes of binary code. In 2022, seriously? TSDuck is not designed to run on an STM32 microcontroller with 64 kB RAM. TSDuck works fine on a Raspberry Pi and I am not interested in increasing the entropy of the mainstream code to support smaller devices.

That being said, TSDuck is open source with a liberal license. Anyone interested in tweaking the TSDuck code to make it run with only two plugins on a pico-device is free to do so.

[lars18th]

OK. Thank you for your response. Perhaps at some point I'll try to provide a patch with a minimal functionality. Regards.