Message-ID: <488793A1.4040501@redhat.com>
Date:	Wed, 23 Jul 2008 16:25:05 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	"Frank Ch. Eigler" <fche@...hat.com>
CC:	Rik van Riel <riel@...hat.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	systemtap@...rceware.org
Subject: Re: systemtap & backward compatibility, was Re: [RFC] systemtap:
 begin the process of using proper kernel APIs

Hi,

Peter Zijlstra wrote:
> On Wed, 2008-07-23 at 11:04 -0400, Frank Ch. Eigler wrote:
>> Hi -
>>
>> I wrote:
>>
>>>> [...] One significant requirement for us is to keep working with
>>>> older kernels.  [...]
>> Maybe it's worth elaborating on why the need for backward
>> compatibility is different for systemtap than for typical kernel-side
>> code.
>>
>> The bulk of systemtap is a user-space program, and it does very
>> user-spacey things like parsing dwarf and invoking compilers, running
>> network servers.  Soon it will include user-space libraries.  It is so
>> different from the stuff normally found there that no one has AFAIK
>> seriously proposed that the entire software be made part of the kernel
>> git tree.  So it is an ordinary separate user-space package, built by
>> users and distributors.
>>
>> It does happen to *generate* kernel modules.  The way that such a
>> module must interface with any particular kernel is naturally subject
>> to the whims & desires of the kernel du jour.  This is why we have a
>> mass of mechanism to try to automatically speak to each kernel version
>> as appropriate.
>>
>> It is desirable to minimize this mass for obvious reasons.  When a new
>> upstream kernel comes out with a tasty new feature -- or a less tasty
>> API rewrite -- we need to extend systemtap to support that too.  We
>> cannot easily take old support away, because then the same user-space
>> code base would no longer run against actually installed kernels.
>>
>> To draw an analogy, systemtap is somewhat like low-level userspace
>> code like glibc or syslogd or udevd.  I hope no one would seriously
>> propose casually committing code to those packages that would make
>> them unusable on prior kernel versions.  Accepting such a patch would
>> require their maintainers to fork outright every time a kernel change
>> occurs.
>>
>> Things are good however if the low-level userspace changes are
>> backward-compatible, so that the new kernel facility is used when
>> present, but the software does not regress if it is not.  I believe
>> this is what we need to aim for, even though it puts the bulk of the
>> burden on systemtap (or glibc, or ...).
>>
>> I hope this fills in some of the gaps in the background.
> 
> Why does a new version of stap have to work on ancient kernels?
>
> A new gnome version requires a new gtk version, a new kde version
> requires a new qt etc.. so why does a new stap not require a new kernel?
> 
> Why isn't only supporting the last few kernels, say for example as far
> back as there are -stable series at the moment of release, good enough?
> 
> People who insist on running stale kernels are usually the same people
> who run stale userspace - we call those enterprise people - so why can't
> they run matching stale version of the kernel and stap?

I agree with you. currently, systemtap is increasingly evolving
on single source tree. But it is obvious that this developing style
can't catch up the upstream development.
I'd like to suggest that we might better branch the tree --
one is stable tree for old kernel, another aims to merge into upstream.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.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/

Powered by blists - more mailing lists