Message-ID: <1326380042.7642.73.camel@gandalf.stny.rr.com>
Date:	Thu, 12 Jan 2012 09:54:02 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	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>,
	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)

On Thu, 2012-01-12 at 09:09 -0500, Mathieu Desnoyers wrote:


> It is important to clarify that tracing is, in my opinion, not part of
> the runtime support, which makes it very different by nature from
> filesystems and kernel runtime support. So I agree with Linus' argument
> about not breaking userspace when applied to runtime support, because
> being unable to even boot a system due to an ABI breakage is very much
> unwanted. However, I think it should not be applied as-is to tracing,
> because you cannot make a system unusable due to a tracer ABI breakage:
> if a tracer can be packaged in a set of standalone modules, that clearly
> shows it is not part of the system runtime support.

Correct that tracing is not something that needs to make the system run,
but that's still no excuse to make ABI changes any different. Note, we
don't change things within the /proc/stat or /proc/*/stat and that's not
required to make the system run. We can add onto those files, but we
can't change what the current numbers mean.

> 
> That being said, ABI versioning could still handle ABI changes without
> significantly impacting the users: when an ABI breakage is needed, we
> can keep the old code around for a while and expose both the old and new
> ABIs. This would ensure that the user-level tools can query for the
> specific ABI major version(s) they support. That should improve the user
> experience by providing "deprecated" console warnings for a few kernel
> releases before the old code ends up being removed.

ABI version numbers are meaningless, and prone to be broken. The change
would have to be added with the commit that updates the change otherwise
git bisecting can get screwed up too.

The way ABI changes in the kernel have always been was to look at the
file itself and have the tool be able to determine what version of the
ABI is there based on what files exists, or what exists in the file.
I've done this with trace-cmd and ftrace. The debugfs system has changed
a lot, and trace-cmd can handle each change. I never had a need for a
version number to do this. I simply have trace-cmd look at what is
available and what isn't.

If you need to know if a syscall exists, you try it and if you get
-ENOSYS, then you know it doesn't exist. We have no need for an
arbitrary version number that is meaningless. The existence of (or lack
of) tells us all we need to know.


> 
> So, in summary:
> 
>   * Old kernels vs new tools:
> 
> New tools can query for the latest ABI they know, and fall-back on older
> ABIs, with limited features.
> 
>   * New kernels vs old tools:
> 
> Keeping around the old ABI for a deprecation phase lets old tools work on
> a bleeding edge kernel while the ABI change is being introduced, which
> should satisfy the kernel developer use-case.

We've done this without version numbers. Just look at all the udev
changes.

-- Steve


--
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/

Powered by blists - more mailing lists