>> The Debian/Ubuntu packages for liblttng-ust and liburcu are >> multiarch-enabled, so you can install the :i386 and :amd64 versions in >> parallel. That way they will be tracked by the package manager, and won't >> "linger around". > Except that the Ubuntu LTTng packages are hopelessly behind right now. I > wanted to do everything with the 2.3.0 release.
The packages from the official repo are often behind, yes. But we have an Ubuntu PPA which follows the stable releases: https://launchpad.net/~lttng/+archive/ppa It's updated daily with the contents of the stable-* git branches. > On a different note, why does LTTng have 32- and 64-bit consumers anyway? > The only possible difference between a 32-bit tracer and a > 64-bit tracer is that the latter could generate event record fields that are > 64-bit longs and floats, while the former cannot (but will never > have to, since the application it is tracing won't have such beasts anyway). > So the 64-bit consumer should be backward compatible with the > 32-bit consumer, because it deals with a super-set of the 32-bit consumer > requirements. If this were the only difference, LTTng would not > need a separate 32-bit consumer daemon. Is there some sort of > context-switching overhead associated with a 64-bit daemon accessing a > buffer that exists in a 32-bit process context? The performance gain would > justify the existence of a 32-bit consumer, I suppose. The consumer shares memory space with the traced process, so they have to use the same ABI. If they talked only through let's say a pipe, that wouldn't be necessary, but performance would indeed be much worse. Cheers, Alex _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
