[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 Oct 5 04:49:11 EDT 2016


Hi,

On 5 October 2016 at 07:17, Lipka, Christoph (ADITJ/SWG) <
clipka at jp.adit-jv.com> wrote:

> Hi Tobias,
>
>
>
> I am interested to try your patch in the mentioned container scenario.
> Could you guide me to have a minimal demo setup I can test your patch?
> Thanks.
>

Currently, no. The setup we have is rather large (LXC based containers),
but we are working on creating something smaller where we can test this
properly. This is a priority issue for us, so we will definitely work on
getting it fixed.


> Btw: We are currently merging the patch on top of current master to get a
> feeling how the daemon might look like and behave. It would be great if you
> can also have a look on the patch later.
>

I would be happy to!


>
>
> @Jeremiah: Might it be possible to handle this as pull request for
> community review in github? I anyhow don’t really like the current approach
> of sending patches to mailing list, since nearly nobody is checking patches
> or gives comments.
>

I agree, plus it gives much better opportunities to track changes +
discussion together.


>
>
> 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 *Jeremiah Foster
> *Sent:* Friday, September 16, 2016 1:35 AM
>
> *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)
>
>
>
>
>
>
>
> 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-requi
> red-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-diag
> nostic-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-diag
> nostic-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
>
>
> _______________________________________________
> 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-diag
> nostic-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/20161005/602e2c70/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.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/20161005/602e2c70/attachment.png>


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