linux-kernel - Re: Perf ABI (was: Re: [lttng-dev] [PATCH 09/11] sched: export task

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 23 Dec 2011 13:16:41 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Ted Ts'o <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
	Greg KH <greg@...ah.com>, devel@...verdev.osuosl.org,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, lttng-dev@...ts.lttng.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: Perf ABI (was: Re: [lttng-dev] [PATCH 09/11] sched: export
	task_prio to GPL modules)

Hi Ted,

* Ted Ts'o (tytso@....edu) wrote:
> On Fri, Dec 23, 2011 at 11:46:29AM -0500, Mathieu Desnoyers wrote:
> > - It's doing so without even needing it: Perf is using an ABI versioning
> >   scheme designed for filesystems, when it is not in fact driven by the
> >   same constraints.
> 
> Well, there are *some* constraints.  I've been assured that despite
> the fact that the perf client is in the kernel sources (something
> which I still think is a bad idea, since it's leading to other bad
> choices like kvm-tool wanting to be bundled with kernel sources), that
> it is *not* a license to jerk the format around wildly --- that people
> will have installed userspace binaries that shouldn't randomly break
> they boot a new kernel.
> 
> So I'm *glad* that Perf is using an ABI versioning scheme that accepts
> the same restraints as file systems.  It means we don't randomly break
> userspace tools.
> 
> So Mathieu, if you think it is the current standards of backwards
> compatibility are too rigid, what level of tool breakage do you think
> is acceptable?  It's not just about the backwards compatibility of the
> trace files, it's also about compatibility of userspace utilities.
> 
> For example, systemtap, where you had to recompile from source at
> each kernel revision, and pray it would still build goes too far in
> the other direction, wouldn't you agree?  What is the correct level of
> kernel developer annoyance you think is appropriate to inflict on
> ourselves?

I completely agree that systemtap did not have the right level of
compatibility towards changes. It clearly does not make sense to require
the tools to be updated whenever the kernel version and instrumentation
changes. What makes sense to me, though, is to allow breakage when a
newly introduced tracer feature requires the ABI to break.

What I currently see as a tradeoff sweet-spot between compatibility
burden and ability to innovate is to split the ABI and handle
compatibility as follows:

- ABIs to control the tracer
  - Versioned, ideally always incrementally adding features, but still
    keeping room for major changes if needed. We should expect very,
    very seldom breakages on this front. This requires update of tracer
    control tools when the ABI is broken.

- ABIs to transport tracing data
  - Versioned, can and should change when a feature or transport
    performance enhancement require to break compatibility. This
    requires update of trace data consumer tools when compability is
    broken.

(note that ABI to control the tracer and ABI to transport data could
share the same version numbering if the control tools and transport
tools happen to reside in the same user-level packages)

- The trace data format
  - Both versioned _and_ self-described.
  Self-description of the event/field layout allows the same tools to
  understand traces gathered on different kernel versions, on different
  architectures, with different tracer configurations.
  Versioning on top of the self-described trace format allows changes
  to what the trace self-description can express.

So the breakages would happen only when required by tracer tool
capability enhancements, not randomly when a kernel instrumentation
source happens to change.

Best regards,

Mathieu

P.S.: my next replies will be slightly delayed, due to Christmas
holidays.

> 
> Regards,
> 
> 
> 						- Ted

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/