linux-kernel - Re: perf & rasd integration plan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Oct 2014 11:13:15 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Jean Pihet <jean.pihet@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Fu Wei <fu.wei@...aro.org>, Robert Richter <rric@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Matt Fleming <matt@...sole-pimps.org>
Subject: Re: perf & rasd integration plan

Em Tue, Oct 07, 2014 at 04:02:29PM +0200, Borislav Petkov escreveu:
> 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.

Ok, at some point we need to make sure this gets into tools/lib/api/README.
 
> See, no need for you to get over to LCE: we're practically done :-)

Nah, there is much more than this at LCE, I'm sure, I'll try again next
time.
 
> 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.

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

For me one of the points of having tools/ is to try and make kernel
developers try to do userspace muck, dirtying the hands trying to use
the same discipline used in the kernel proper, using code as unchanged
as possible from the kernel proper, etc.

If we now are moving to share code in a way that keeps what is nice in
having code and its users in the same repo, like the kernel guys have
with subsystems and its drivers while allowing to do it in different
repos, that is a good thing indeed.
 
> Haha.

While having fun even! Good deal.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/