Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On 18/10/2013 22:18, Timo Juhani Lindfors wrote:
> It is certainly meant to be usable for software that wants to use SDT
> probes (like glibc in this example) and software that wants to
> read/inspect the SDT probes embedded in other software (like gdb in this
> example).
So the SDT probes provided by systemtap-sdt-dev are not kernel-specific?
>> I don't think it does any serious harm to kfreebsd-* ports that
>> systemtap-sdt-dev is available despite that it is unusable. However if
>> this is inconvenient for other reasons, we really can't help you about
>> it. This package shouldn't be provided for kfreebsd-* in first place.
>
> Does kfreebsd use gcc/glibc/gdb/etc? Then it should be available for it
> so that software that uses STAP/DTRACE_PROBE SDT macros can be build on
> it.
>
> The confusion might be that it has systemtap- in the package name (that
> is because it originated through the systemtap project). And systemtap
> at the moment is indeed linux kernel specific. But the sys/sdt.h header
> (and dtrace compatible python script) provided by the package are not
> tied to systemtap at all. Other tools like perf and gdb provide other
> consumers of the SDT probes.
It seems the namespace collision is not by chance. The <sys/sdt.h> in
systemtap is probably inspired by a DTrace version of <sys/sdt.h>, which
is what FreeBSD kernel headers seem to be providing.
How compatible are the different implementations? If they're meant to be
bit-by-bit compatible, then it should be possible for systemtap-sdt-dev
to just skip this file on kfreebsd-* so that applications will use the
FreeBSD version. Do you think this could work?
If 100% compatibility is not a goal, then IMHO it makes no sense for
systemtap-sdt-dev to (ab)use the <sys/*> hierarchy. This part of the
namespace is supposed to be for system headers only.
--
Robert Millan
Reply to: