[genivi-dlt] Diagnostic Logging and Tracing for GDP, take 2

Gunnar Andersson gandersson at genivi.org
Wed Jul 12 17:31:55 EDT 2017

Forwarded because I got the address wrong for the DLT list...

Date: Wed, 12 Jul 2017 13:40:16 +0200
Subject: Diagnostic Logging and Tracing for GDP, take 2
To: PHILIPPE COLLIOT <philippe.colliot at mpsa.com>, genivi-
projects at lists.genivi.org <genivi-projects at lists.genivi.org>, genivi-
diagnostic-log-and-trace-request at lists.genivi.org <genivi-diagnostic-log-and
-trace-request at lists.genivi.org>
From: Gunnar Andersson <gandersson at genivi.org>

Hi Philippe, and others

I heard you were instrumenting some of your C++ code with more calls to DLT,
so I promised to provide more info about the C++ API, and I can also add
some more to Oscar's introduction.

So as a reminder, Oscar Andreasson recently sent out this email to explain
the current intention for GDP [1] which then becomes a _recommendation_ for
components that we include in GDP.

In choosing an API we might consider:

1. Convenient/efficient API
2. Combine all or most logs into a single system, and choose what we believe
to be the best logging backend, for us, right now.
3. Provide an abstraction/flexbility to change logging backends, for us as
well as other adopters of the software.

Meeting all 3 comes at a cost, and there is a trade-off here that led us to
different recommendations for different types of programming environments. 
(Feel free to provide your feedback).

The ivi-logging C++ class makes it more convenient to create logs using a
C++ style API (1) so we recommend that for C++ projects.  It supports DLT
right away (2) and also prepares alternative logging backends (3)!

But for C-code, if another API (3) was created on top of DLT, I bet it would
end up being very similar.  It will just be the same, but with different
function names.   So doing that does not provide a major usability benefit
(1).  Even if a set of wrappers were written, it is not guaranteed that the
 new API will be adopted by other projects that are not using DLT either, so
the effort seemed wasted.   Our idea is that most likely a C project that
might want to switch from DLT to something else can quite easily do so with
a search-and-replace operation across the whole code base, when the time

Therefore we decided to recommend programming with DLT directly as the main
direction for C code.  Note, this is just the GDP common direction and
recommendation.  I stand by the intention to have GENIVI component
maintainers in charge of their own project, and depending on how components
are shared with others, the trade-off balance might shift for you.  Just go
with the default recommendation if you have no other, and in all cases, keep
the conversation channels open.

Since Oscar's email, we have one addition.  We realized that Qt-specific
code benefit from using the qDebug() macro because it knows how to properly
print all kinds of Qt datatypes, which ivi-logging does not directly
support.  Qt programmers are of course also more used to qDebug().  Ivi-
logging would basically have to repeat the code that decodes Qt datatypes to
nice printouts and that did not seem to make sense.

Instead, there is already an official module in the Qt Project that connects
qDebug() to DLT:

   See Qt GENIVI Extras at [2].

However, to use QtGENIVExtras while still being compliant with current
license policies, only the GPLv2 license would be applicable, and not the
alternative LGPLv3.  So that means Qt demonstration programs should likely
make sure to be GPL licensed.  The code also needs to be backported into our
system since it does not come with the current Qt 5.6.1

Using GPL should be little problem I expect because:

1. First (let me repeat that) for a generically reusable platform like GDP,
Qt should only be used on the graphical API and not be tied into services /
platform components.

2. Second, all GDP code is already open-source, and any graphical
applications shown in GDP are considered "demos" anyway.  Apps and HMI tends
to be proprietary and the current apps are unlikely to be used as they are
by any final OEM product.

The tricky detail is still code that gradually evolves from prototype to
production.  For me, this is still a bit of a minefield, but for those
aspects I can only refer you to the Qt Company's recent email on the subject
(see archives).

What remains is just to see if there are any blockers to relicensing any
existing demo apps from, for example, MPL to GPL.

So here is a summary of the recommendations, as we see them now:

1. For C++ - program against the ivi-logging base class / interface [3], and
as implementation use the already provided subclass that writes the output
to DLT [4].

2. For C - use the DLT interfaces directly*.

3. For Qt C++ programs, use qDebug. (ivi-logging for any code modules that
are not tied to Qt), and QtGENIVIExtras** and license the program using

*For all of the above, artistic freedom allows for making convenience
macros/functions or other, as it fits your component best.

**As you can see, there's some work to do to integrate and review licensing
and such for point 3, but if you are blocked on any of that happening more
quickly, then just let someone know.  Keep the conversation open.

Best Regards,
- Gunnar

P.S. Maybe someone in the future wants to send a patch that renames ivi-
logging to something like automotive-logging, since it's unlikely to be IVI

[1] https://lists.genivi.org/pipermail/genivi-projects/2017-June/005575.html
[2] https://doc.qt.io/QtGENIVIExtras/
[3] https://github.com/Pelagicore/ivi-logging/
[4] https://github.com/Pelagicore/ivi-logging/blob/master/include/ivi-logging-dlt.h

More information about the genivi-diagnostic-log-and-trace mailing list