linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Primiano Tucci <primiano@google.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: rostedt <rostedt@goodmis.org>,
	"Joel Fernandes, Google" <joel@joelfernandes.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	aneesh kumar <aneesh.kumar@linux.ibm.com>,
	 Carmen Jackson <carmenjackson@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	 Daniel Colascione <dancol@google.com>,
	jglisse@redhat.com, linux-mm <linux-mm@kvack.org>,
	 Mayank Gupta <mayankgupta@google.com>,
	Michal Hocko <mhocko@suse.com>,  Minchan Kim <minchan@kernel.org>,
	mm-commits@vger.kernel.org, rcampbell@nvidia.com,
	 Tim Murray <timmurray@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [patch 026/158] mm: emit tracepoint when RSS changes
Date: Tue, 3 Dec 2019 10:44:36 +0000	[thread overview]
Message-ID: <CA+yH71d0R8-D1mUFPnZa7JWBL-Z6Ktwj2wibircU-ZeK8PpkKg@mail.gmail.com> (raw)
In-Reply-To: <2084584347.3560.1575351504972.JavaMail.zimbra@efficios.com>

On Tue, Dec 3, 2019 at 5:38 AM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> ----- On Dec 2, 2019, at 9:48 PM, Primiano Tucci primiano@google.com wrote:
>
> > On Mon, Dec 2, 2019 at 11:53 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Mon, 2 Dec 2019 18:45:14 -0500
> > Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> >>
> >> I would love for that to happen but I don't develop Perfetto much. If I am
> >> writing a tool I will definitely give it a go from my side. CC'ing Perfetto's
> >> lead developer Primiano -- I believe you have already met Primiano at a
> >> conference before as he mentioned it to me that you guys met. I also believe
> >> this topic of using a common library was discussed before, but something
> >> about licensing came up.
> >
> > Oh hello again!
> >
> >> libtraceevent is under LGPL, is that an issue?
> >
> > Unfortunately yes, it is :/
> > Our process for incorporating GPL or LGPL code makes Perfetto [1] (which is
> > Apache-2 licensed) problematic for us and recursively for other projects that
> > depend on us.
> >
> > For context, Perfetto is a cross-platform tracing project based on shmem and
> > protobuf, shipped on production devices and used by other app-developer-facing
> > tools (e.g. [6, 7]). It deals with both:
> > (1) pure userspace-to-userspace tracing (on all major OSs).
> > (2) kernel tracing via ftrace/tracefs (only on Linux/Android).
> > https://docs.perfetto.dev/ explains it a bit more.
> >
> > Today Perfetto is embedded and used both by Chrome [2] and Android platform [3].
> > For both projects, pulling LGPL-licensed code is cumbersome process-wise: It
> > would require us to put mechanism in place to guarantee that the relevant LGPL
> > dependencies don't get accidentally linked in any production binary but only
> > used for the standalone offline tools to analyze traces.
> > Such process is unfortunately very expensive to setup and maintain for us and
> > for the projects that depend on us.
> > I don't want to start an ideological battle about licensing. To be clear, I
> > don't have any issues with LGPL, nor I think there's anything inherently
> > wrong with it. Just, it makes things too complicated when a smaller sub-project
> > like ours is embedded in larger projects.
>
> Just to clarify: my understanding is that a constraint that requires no dynamic
> linking of proprietary code on LGPL libraries does not seem to originate from
> restrictions based on the wording of the LGPL text. So it appears to be self-imposed
> either by your employer's (or your own) additional requirements, so not to bother
> dealing with the legal side of compliance, am I correct ?

Essentially adding a LGPL dep for us is the moral equivalent of putting
a sticker on the project that says "This needs to be handled with care now".
Any new user of the project would need to go through the process of
putting build-time scripts/checks in place to ensure that the dynamic linking
requirements are not accidentally violated.
In large projects with hundreds of build targets (like the aforementioned
ones which embed Perfetto today), refactorings happens every single day.
The risk of somebody pulling unwanted deps by accident is non-zero.
Licensing is not something that one can risk to accidentally get wrong,
hence we are required to do our best to avoid those mistakes.

Furthermore, from a pure technical viewpoint, dynamic linking is a major pain
for many cross-platform projects because has different subtleties on each
platform. Most projects just ship big statically linked monoliths.
Having a LGPL dependency in Perfetto means telling them "if you want to use
this tracing project you need to change your build rules / packaging strategy
and start dealing with dynamic linking on four different platforms
(Linux, Android, Mac, Windows)". This would be a show-stopper for our
project.

Primiano


>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com



--
Primiano Tucci
Software Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ


  reply	other threads:[~2019-12-03 10:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01  1:50 [patch 026/158] mm: emit tracepoint when RSS changes akpm
2019-12-02 17:14 ` Steven Rostedt
2019-12-02 21:13   ` Joel Fernandes
2019-12-02 21:56     ` Steven Rostedt
2019-12-02 23:45       ` Joel Fernandes
2019-12-02 23:53         ` Steven Rostedt
2019-12-03  2:48           ` Primiano Tucci
2019-12-03  5:38             ` Mathieu Desnoyers
2019-12-03 10:44               ` Primiano Tucci [this message]
2019-12-03 15:58                 ` Steven Rostedt
2019-12-04  4:08                   ` Joel Fernandes
2019-12-03 14:53             ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+yH71d0R8-D1mUFPnZa7JWBL-Z6Ktwj2wibircU-ZeK8PpkKg@mail.gmail.com \
    --to=primiano@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=carmenjackson@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dancol@google.com \
    --cc=jglisse@redhat.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-mm@kvack.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mayankgupta@google.com \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=rcampbell@nvidia.com \
    --cc=rostedt@goodmis.org \
    --cc=timmurray@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).