[genivi-dlt] Patch moving dlt-daemon from FIFO to UDS (was: Issues with mechanism to change log-level)

Tobias Olausson tobias.olausson at pelagicore.com
Wed Sep 14 03:38:49 EDT 2016


Hi,

On 6 September 2016 at 08:51, Lipka, Christoph (ADITJ/SWG) <
clipka at jp.adit-jv.com> wrote:

> 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.
>

I see, and that is of course reasonable.

2. we have another issue concerning DLT Session handling which we want to
> solve when anyhow changing the application connection handling. [4]
>

Is this really the same issue? Applications inside a container still have a
pid, so I'm not sure if it breaks the current Session ID idea (the
container issue is that there are different pid namespaces and therefore
one dlt-daemon can't map the inside pid to the outside one).


>
> One question: Sorting (target time ordered) has to be done inside DLT
> Viewer when this approach is used, is this correct?
>

I don't know enough about the DLT internals to confidently answer that.


>
> 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.
>

That would be great.


>
> 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
>
> _______________________________________________
> genivi-diagnostic-log-and-trace mailing list
> genivi-diagnostic-log-and-trace at mailman1.genivi.org
> http://lists.genivi.org/cgi-bin/mailman/listinfo/genivi-
> diagnostic-log-and-trace
>
>


-- 
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/20160914/26035c38/attachment.html>


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