Re: [PATCH 0/1] libevl: Add debian package config

On 21.07.26 00:22, Hannes Diethelm wrote:
> Am 20.07.26 um 16:30 schrieb Jan Kiszka:
>> Hi Hannes,
>>
>> thanks for carrying this over.
> 
> Thanks for all the feedback.
> 
>>
>> On 17.07.26 22:58, Hannes Diethelm wrote:
>>> This patch adds a debian package config that allows to build a deb's
>>> using dpkg-buildpackage -b -uc.
>>>
>>> The packages are libevl / libevl-test similar to[1]. However, latmus
>>> is placed in libevl. One might not need the tests but still want to
>>> use latmus.
>>
>> For the purpose of tuning the core, or what is the reasoning here?
> 
> Yes exactly. One might need latmus but won't care about the tests.
> 
> Based on the comment from Florian, it would probably make more sense to
> create more packages:
> 
> - libevl (only library)
> - libevl-bin (evl / latmus / oob-* tidbits)
> - libevl-test (tests)
> - libevl-dev (headers / libevl.a)
> 

Alternatively, maybe there is a way to split off the tuning feature from
latmus tool, like we have with autotune in xenomai3.

>>
>>>
>>> Additionally, libevl installs /usr/lib/udev/rules.d/90-libevl.rules
>>> which sets all evl
>>> device files to group evl, g+rw. libevl.postinst adds this group and
>>> triggers an udev reload.
>>>
>>> This allows to use libevl without root. However, using SCHED_FIFO still
>>> needs either root or setcap cap_sys_nice+ep and possibly some other
>>> tweaks.
>>> Some tests and my application work with cap_sys_nice+ep. However, for
>>> example latmus fails
>>> due to unknown reasons. The debian packages sets no capabilities but
>>> this could be added
>>> if desired.
>>>
>>> Caveats:
>>>
>>> The test ptrace-sync fails with <timeout waiting for gdb>. dh_strip -
>>> Xptrace-sync from[1]
>>> does not help and it is not needed: When libevl-test-dbgsym is
>>> installed, the symbols are
>>> available but the test still fails. With dh_strip -Xptrace-sync, the
>>> symbols are not found:
>>> warning: could not find '.gnu_debugaltlink' file for /usr/libexec/
>>> evl/tests/ptrace-sync
>>
>> But the package built by xenomai-images does not have this problem and
>> runs the ptrace test successfully. Already dug into the key differences?
> 
> Not yet. Might be just a different gdb version or path issue. I am using
> Debian Trixie.
> 
> Is there a way to download this images? I've seen there is a way to
> build them locally, i can also try this.
> 

We do not ship pre-built images, you would have to build your own image
here.

>>
>>>
>>> If linux-evl is also built and installed as a debian package, linux-
>>> libc-dev can not be
>>> installed due to /usr/include/evl/*-abi.h are both installed by
>>> libevl and linux-libc-dev
>>> from the kernel build. However, installing linux-libc-dev from debian
>>> trixie works fine.
>>
>> This looks wrong: The kernel is providing us with a different UAPI, thus
>> also needs to deliver an alternative linux-libc-dev package. It should
>> be the role of libevl to deliver those headers as it has no knowledge
>> about the actual kernel in use here. That's why xenomai-images is
>> generating a new linux-libc-dev and is not relying on libevl here.
>>
> 
> Yes, Philippe sent me the hint with the -Dinstall-uapi=false switch,
> thanks.
> 
> One remaining issue is the versioning / dependency's. For now, to keep
> it simple, I just used the libevl tag
> as the version. And it doesn't recommend a xenomai4 kernel.
> 
> For now, the packages are:
> libevl_59_amd64.deb
> libevl-test_59_amd64.deb dep libevl >= 59
> linux-image-6.12.90-cip24-xenomai4-r59_6.12.90-3_amd64.deb (Withouth
> PREEMT_RT)
> linux-image-6.12.90-cip24-xenomai4-r59-rt_6.12.90-3_amd64.deb (With
> PREEMT_RT)
> 
> I am working here [1] on creating Debian xenomai4 packages for linuxcnc.
> Not perfect but does the job. It's still WIP
> but a few people got this already working without knowledge how to build
> kernels.
> I did not yet push the latest version and I have to change from pushing
> the binary's to github releases.
> 
> With the uapi installed with linux-libc-dev, libevl has to depend on the
> right linux-libc-dev.
> 
> Version 59 is not really correct. The kernel has EVL ABI 45. Libevl has
> API 36, needs API >= 45.
> For kernel dependency's, the ABI version is important, right?
> 
> For libevl, it could be either the API = 36 / dso_version = 8.0.0 /
> version = 0.59.
> 
> Variant with API/ABI as version:
> - libevl 36 recommends linux-image-xenomai4 >= 45 or linux-image-
> xenomai4-rt >= 45
> - libevl-bin 36 dep libevl >= 36
> - libevl-test 36 dep libevl >= 36
> - libevl-dev 36 dep libevl >= 36 linux-libc-dev >= 1:45
> 
> Dependency packages, needed to convert the ABI versioning into kernel
> versioning:
> - linux-image-xenomai4 45 dep linux-image-6.12.90-cip24-xenomai4-45 or
> other kernel versions
> - linux-image-xenomai4-rt 45 dep linux-image-6.12.90-cip24-xenomai4-
> rt-45 or other kernel versions
> - linux-libc-dev 1:45 dep linux-libc-dev-xenomai4-45
> 
> Kernel packages:
> - linux-image-6.12.90-cip24-xenomai4-45 6.12.90
> - linux-image-6.12.90-cip24-xenomai4-rt-45 6.12.90
> - linux-libc-dev-xenomai4-45 6.12.90
> 
> To create a linux-libc-dev-xenomai4-45 package, I would have to add a
> patch for linux-evl, the standard
> kernel debian package system doesn't support custom names for linux-
> libc-dev. But this should be not to
> complicated.
> 
> It's the first Debian package I am working on that's not only for me. I
> have to read a bit more in the
> doc's how this dependency's are normally created properly.
> 
> Also linux-libc-dev 1:45 is a bit dirty: Using the epoch to replace the
> standard linux-libc-dev by a dependency
> package that will not be replaced by the latest stock one. It should
> work tough.
> 
> Alternatives:
> -Install the abi with libevl
> -Create a linux-libc-dev-xenomai4 package from linux-evl and depend on
> that / remove the evl headers from linux-libc-dev
>  so linux-libc-dev stock can be installed together with linux-libc-dev-
> xenomai4. I compared the content, most evl related files
>  are new, only fnctl.h has
>  #define O_OOB        010000000000
>  added. However, I don't see any usage in libevl. So this should work.
> -Leave the dependency's on the kernel packages away and solve this by
> documentation
>  However, you would have to place a hold on linux-libc-dev so it doesn't
> get replaced as soon as your OS has a newer kernel.
> 
> Do you have other ideas how to solve the version / dependency's / linux-
> libc-dev issue?
> 
> For now I named the kernel packages -xenomai4 but I am thinking about
> changing to -evl or xenomai-evl. What is more appropriate?

The topic is complicated because neither Debian nor other packaging
systems I know allow to express this two-dimensional version dependency
(>= ABI version X, latest kernel Y). If you encode the ABI into the
package version as well, you are folding that version matrix into a
single version number (>= abi-X-kernel-Y, or >= kernel-Y-ABI-X) - none
is perfect.

If your target audience for those packages primarily consists of
beginners, it will be best to model it via a lock-step between libevl
and some kernel package that carries a specific ABI version in its name
(linux-image-evlX_kernel-ver-Y etc.). This implies creating a
linux-libc-dev flavor as well (linux-libc-dev-evlX or so). That package
should carry Provides:, Conflicts:, and Replaces: for linux-libc-dev in
its metadata.

We side-step all these issues in xenomai-images by generating and
installing a set of custom packages in a curated environment where
upstream will not be able to replace the self-build xenomai packages
(preferences are set accordingly for local repo with those packages).

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center