All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jean Pihet <jean.pihet@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Fu Wei <fu.wei@linaro.org>, Robert Richter <rric@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, David Ahern <dsahern@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Matt Fleming <matt@console-pimps.org>
Subject: Re: perf & rasd integration plan
Date: Tue, 7 Oct 2014 16:02:29 +0200	[thread overview]
Message-ID: <20141007140229.GF30146@pd.tnic> (raw)
In-Reply-To: <20141007135531.GI14113@kernel.org>

On Tue, Oct 07, 2014 at 10:55:31AM -0300, Arnaldo Carvalho de Melo wrote:
> So you say that if we change a method, say, perf_evlist__open() to
> accept a new argument, or change the type of one of its arguments,
> with a good reason, it is acceptable and with just a change in the
> README explaining why the build fails, which helps in finding how to fix
> it in a particular project using these "source libraries" then it would
> be ok?

Right, exactly.

Updating the perf bits used in another project will require a
recompilation anyway so adjusting stuff here and there should not be of
issue.

> That would be fine with me.

Yeah.

> We should take care to make sure that the build _fails_ in such cases,
> i.e.avoid changing the semantic of the Nth argument but keeping its
> type kind of changes.

Yep.

> At some point there will be no more reasons to change things, and that
> will be noticed by how long since the last change was made to a
> particular class, at that point we may well think about making library
> type promises.

I was about to say the same thing - once the code doesn't change anymore
and gets even boring, doing the library promise is probably pretty easy.

See, no need for you to get over to LCE: we're practically done :-)

We'll run the proposal in jolsa's timeslot again and make sure to poke
holes in it. But it looks good from where I'm standing.

Btw, did we just solve the compatibility problem of libraries by
delivering source libraries first!?!

Haha.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-10-07 14:02 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30  9:06 perf & rasd integration plan Jean Pihet
2014-09-30 13:24 ` Arnaldo Carvalho de Melo
2014-10-05 17:48   ` Borislav Petkov
2014-10-05 18:24     ` Jiri Olsa
2014-10-05 18:45       ` Borislav Petkov
2014-10-05 19:24       ` Chuck Ebbert
2014-10-05 19:28         ` Jiri Olsa
2014-10-06  6:53       ` Jean Pihet
2014-10-08  6:59         ` Jiri Olsa
2014-10-06  9:07   ` Robert Richter
2014-10-06 13:44     ` Jean Pihet
2014-10-06 14:58     ` Arnaldo Carvalho de Melo
2014-10-06 15:01       ` Borislav Petkov
2014-10-06 15:08         ` Arnaldo Carvalho de Melo
2014-10-06 15:16           ` Borislav Petkov
2014-10-06 15:02       ` Jean Pihet
2014-10-06 15:07 ` Arnaldo Carvalho de Melo
2014-10-06 15:16   ` Borislav Petkov
2014-10-06 19:12     ` Arnaldo Carvalho de Melo
2014-10-06 19:53       ` Borislav Petkov
2014-10-06 21:22         ` Arnaldo Carvalho de Melo
2014-10-07 11:23           ` Borislav Petkov
2014-10-07 13:40             ` Arnaldo Carvalho de Melo
2014-10-07 13:49               ` Borislav Petkov
2014-10-07 13:55                 ` Arnaldo Carvalho de Melo
2014-10-07 14:02                   ` Borislav Petkov [this message]
2014-10-07 14:13                     ` Arnaldo Carvalho de Melo
2014-10-06 21:26 ` [PATCH 1/1] rasd: Use perf_evlist__open() instead of open coded Arnaldo Carvalho de Melo
2014-10-07  8:45   ` Jean Pihet
2014-10-07 13:32     ` Arnaldo Carvalho de Melo
2014-10-07 14:04       ` Borislav Petkov
2014-10-07 14:17         ` Arnaldo Carvalho de Melo
2014-10-10 20:07         ` Arnaldo Carvalho de Melo
2014-10-10 20:28           ` Borislav Petkov
2014-10-10 20:41             ` Arnaldo Carvalho de Melo
2014-10-10 20:44               ` Borislav Petkov
2014-10-13  7:29                 ` Jean Pihet
2014-10-14 13:56                   ` Jiri Olsa
2014-10-14 14:02                     ` Arnaldo Carvalho de Melo
2014-10-14 14:22                       ` Jiri Olsa
2014-10-14 15:17                         ` Borislav Petkov
2014-10-14 15:20                           ` Jean Pihet
2014-10-14 14:19                     ` David Ahern
2014-10-14 17:09                       ` Arnaldo Carvalho de Melo

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=20141007140229.GF30146@pd.tnic \
    --to=bp@alien8.de \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=fu.wei@linaro.org \
    --cc=jean.pihet@linaro.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@console-pimps.org \
    --cc=mingo@kernel.org \
    --cc=rric@kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.