Hi Tobias,
I like the approach (even if I haven’t tried to build and run yet), we are also concerning the FIFO based approach because of the issues mentioned in [1]. Also the direct knowledge of disconnected applications is a big plus (no need for some “heartbeat messages” as we might need with the FIFO approach to get the same result). In an ideal case, this information ((un-)register applications, contexts) should be forwarded to the DLT Viewer instead of relying on the GetLogInfo message. This is *somehow* already implemented with the DLT Daemon internal messages, but this information is not used inside DLT Viewer.
Actually, I see two issues with the patch provided in [2].
1. It does not fit into the epoll based event/connection handling we introduced some time back [3]. A complete rework of the patch is needed.
2. we have another issue concerning DLT Session handling which we want to solve when anyhow changing the application connection handling. [4]
One question: Sorting (target time ordered) has to be done inside DLT Viewer when this approach is used, is this correct?
I wonder how to satisfy our different use cases with a single solution. I really appreciate to start a detailed discussion on this topic, I guess other companies also some use cases in mind which should be considered as well.
Best regards
Christoph Lipka
Software Group (ADITJ/SWG)
Tel. +81-(0)566 61-5124
[3] http://git.projects.genivi.org/?p=dlt-daemon.git;a=commit;h=d29b6be9496db80e37a452bd42dc7813f369c33e
[4] DLT Session Handling
Consider the following problem: There is an application using DLT that is linked to shared libraries that use DLT by their own (register an application and contexts). The same shared library is used by another application that may or may not use DLT itself. The following applications have to be registered:
- For first the following DLT application ID are registered: ‘APP1’, ‘LIB1’, ‘LIB2’.
- And for the second: ‘LIB1’
Registering multiple APIDs per application and having multiple instances of the same module (shared libraries in Linux case) is totally fine from AUTOSAR standard point of view, but not implemented in GENIVI DLT correctly (neither in DLT Daemon nor in DLT Viewer). Each software module (=> Process in Linux) get a Session ID assigned which is (optionally, but mandatory in the scenario described here) sent as part of the DLT Message Header. Having the Session ID, filtering messages from multiple applications having the same APID becomes possible (same is through for sending control/injection messages back – again this part is not implemented).
Currently the PID is used as Session ID, but this may not be possible anymore when thinking about containers, which is the driving factor for having the rework proposed below. Therefore another approach for handling DLT sessions might be needed.
Having this scenario in mind, other things start to become more difficult, e.g. preconfiguring log level on startup per application/context. Also the GetLogInfo message does not handle Session Information which is a big drawback of getting session related information forwarded to the DLT Viewer. I do not know how this is handled in AUTOSAR environment, but my guess is, that this is not a big issue because of the “static” environment (e.g. no start/stop/restart of applications at runtime, potentially unknown application IDs, …).
From: genivi-diagnostic-log-and-trace [mailto:genivi-diagnostic-log-and-trace-bounces at mailman1.genivi.org] On Behalf Of Tobias Olausson
Sent: Thursday, September 01, 2016 9:24 PM
To: genivi-diagnostic-log-and-trace at mailman1.genivi.org
Subject: [genivi-dlt] Patch moving dlt-daemon from FIFO to UDS (was: Issues with mechanism to change log-level)
Hi,
As mentioned in the first post in the "was" thread [1], when working with containers where there is a different pid namespace in relation to the host, it is not possible to use programs that try to communicate with a dlt daemon living outside the container because the pids won't match during connection setup.
A patch was provided [2] that would solve this problem, but I haven't seen it applied in master. Is there a plan to get it into master? Or has the problem been solved in some other way?
[1] http://lists.genivi.org/pipermail/genivi-diagnostic-log-and-trace/2015-March/000646.html
[2] http://lists.genivi.org/pipermail/genivi-diagnostic-log-and-trace/2015-September/000737.html
--
Tobias Olausson
M.Sc C.S.
Software Engineer
PELAGICORE | Experience Change
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46(0)735-873444
http://www.pelagicore.com/
IRC: wto @ FreeNode
Registered Office Gothenburg, Sweden
Registration No. 556780-4199
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-diagnostic-log-and-trace_lists.genivi.org/attachments/20160906/332dd7f8/attachment.html>