[Development] New Module Request: QtGeniviExtras

[Thiago Macieira]

On Thursday 13 August 2015 10:32:42 Dominik Holland wrote:
> > Another option is to split the category name by the dots and select the
> > first letter of each section. So "qt.qpa.windows" is "qqw", while
> > "qt.widgets.gestures" is "qwg".
> 
> Using that approach i'm already getting 4 clashes of the 10 categories
> we use in one of our projects, so i don't think this is the best
> approach to this. And for me that also sounds like magic which no Qt
> User would understand, how do you think to document that ?

That's what you get when the namespace is so small. Blame the DLT designers 
for the limitations they introduced, not me.

> > You can also add a configuration item to the environment variable or
> > qtlogging.ini, which provides a separate, shorter name. QtGeniviExtras
> > could provide an API to set it programmatically.
> 
> Ok but once you forget to provide the env variable or the logging ini
> all your logging is lost as DLT don't accept logs without a category.

It uses the heuristic short name as above. This would allow logging for 
categories that have no specific DLT short name, such as just about all the 
existing Qt code out there right now.

> Also this looks like something which is suitable for a developer, but
> not for a production system.

Hence the QtGenivExtras way of programmatically setting a short name for a 
category.

We can also introduce another Q_LOGGING_CATEGORY2 macro which can take extra 
parameters and settings. We may also in the process get rid of some ugly 
const_cast I've seen show up in the code.

> > But this starts with writing a DLT backend inside QtCore first.
> 
> Looking at how the logging backends are currently integrated in qtcore
> this sounds like the worst solution of all, as it needs a configure time
> check to enable the DLT logging and it would enable it for all Qt
> libraries and examples.

Correct. I don't understand why this would be bad.

Any Qt that you run on a Genivi system is likely to be compiled by that 
GENIVI-compliant distribution, not the one you download from qt.io or from 
your regular Linux distro. That distribution can enable the DLT backend.

Getting the output for all libraries and examples seems like a benefit to me. 
If you don't want the debugging output in production, you can disable it at 
compile time (QT_NO_DEBUG_OUTPUT) or at runtime. Regular logging could remain 
at info and warning levels.
 
> For development this seems to be very unhandy.

Please explain.

If you're developing a simulated system, you get the output in Creator like 
any other regular logging output. If you run that application on the target 
device, it becomes DLT. Sounds like win-win to me.

> I think the back-channel is really one of the things you can't or better
> you don't want to do in a qtcore backend.

What is the back channel?

> Thiago i totally understand what you are up to and i agree that it would
> be good if it could be easily integrated as a logging backend. But in my
> opinion this is really unpractical, it introduces some magic and a
> special configure time check.

I agree it introduces some magic, but only because of the limitations of the 
logging device in question.

As for the configure-time check, it's no different than slog, journald, syslog 
or the Apple log, the latter of which was proposed but never integrated.

> IMHO the users of QtGeniviExtras and the DLT logging are totally aware
> of how the system works and want to have full control over it.
> DLT is only known in the automotive space and there it's only used for
> GENIVI linux based systems. So i think we talk about a logging solution
> which 90% of the qt community don't know or won't ever use. I really
> don't think this is something which should be integrated into qtcore,
> and should be totally fine to live in it's own repository and in the end
> it's very similar of what the other extra repositories currently do,
> components which doesn't fit and are platform specific are in extras

While I understand that, my opinion is that Qt is supposed to make your life 
easier. If we can integrate with the current system, we should. There's a 
reason why the type converters to CoreFoundation types are in QtCore, not in 
QtMacExtras.

We don't have to achieve 100% support either. Qt's goals is 90% easy, 9% 
doable. The way I see it, those 90% match integrating it into QtCore, with the 
9% extra in the QtGeniviExtras module.

The 1% remaining is out of scope for Qt. If you really need that, you can 
always just use DLT directly since, after all, it's all native code.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center