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

Jeremiah Foster jeremiah.foster at pelagicore.com
Thu Sep 15 12:34:06 EDT 2016


On Thu, Sep 15, 2016 at 12:56 AM, Lipka, Christoph (ADITJ/SWG) <
clipka at jp.adit-jv.com> wrote:

> Hi Tobias,
>
>
>
> We are planning to do some investigation on your patch to check how to
> harmonize the work, but it will take some time.
>

I've created a GitHub repository for dlt-daemon.[1] This currently only has
one branch 'master' but I think it might be good to create a 'development'
branch to land the work that your two teams are doing on DLT.  I'll send
you both invites to join the GENIVI organization. We're using GItHub's team
setup for read-write access control and we plan to take advantage of the
new GitHub features for protected branches[2]. I think the best is to
protect the master branch from writing until it passes checks while patches
and feature development can happen in development or other branches.

What is the feedback from this list?

Cheers,

Jeremiah

1. https://github.com/GENIVI/dlt-daemon
2.
https://github.com/blog/2051-protected-branches-and-required-status-checks



> >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).
>
>
>
> No, it is not the same issue, but somehow related. But right now I don’t
> see any blocking issues having both aligned, it is more the other way
> around – seems to fit together quite well.
>
>
>
> >>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 checked it and messages arrive at DLT Viewer un-ordered when logs coming
> from different applications. Within an application, order seems to be
> ensured.
>
>
>
> Best regards
>
> *Christoph Lipka*
> Software Group (ADITJ/SWG)
>
> Tel. +81-(0)566 61-5124
>
>
>
> *From:* genivi-diagnostic-log-and-trace [mailto:genivi-diagnostic-log-
> and-trace-bounces at mailman1.genivi.org] *On Behalf Of *Tobias Olausson
> *Sent:* Wednesday, September 14, 2016 4:40 PM
> *To:* Lipka, Christoph (ADITJ/SWG)
> *Cc:* genivi-diagnostic-log-and-trace at lists.genivi.org
> *Subject:* Re: [genivi-dlt] Patch moving dlt-daemon from FIFO to UDS
> (was: Issues with mechanism to change log-level)
>
>
>
> 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
>
> _______________________________________________
> 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
>
>


-- 
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +1.860.772.9242
jeremiah.foster at pelagicore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-diagnostic-log-and-trace_lists.genivi.org/attachments/20160915/efd47735/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PELAGICORE_RGB_Black_horizontal.png
Type: image/png
Size: 11841 bytes
Desc: not available
URL: <http://lists.genivi.org/pipermail/genivi-diagnostic-log-and-trace_lists.genivi.org/attachments/20160915/efd47735/attachment.png>


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