Arjan van de Ven <[email protected]> writes:
> [...]
>> 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.
> and this is where I strongly disagree. THIS part *has* to be in the
> kernel source, so that we can change it WITH the kernel as we change
> it. [...] But to have any chance at all of systemtap being
> sustainable, this part of the stack has to be together with where
> the changes happen.
OK. It will take us some time to figure out to what extent this would
be feasible. Maybe a topic for Portland.
>> 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.
>
> At that point you are already 3 months too late for me, and probably
> for most of my fellow kernel hackers.
(Really? Have we ever been 3 months behind supporting the git kernel?)
> (and when it's seen it gets a rather luke warm reception, but that's
> a different story).
I hope the backward compatibility issue, as it stands today, helps
explain the reasons for the current deal with kprobes.
In the interim (before we come up with a way of moving more
kernel-coupled systemtap code into kernel.org/git), would y'all
consider an arrangement? Those of you who care about systemtap, and
are intending to make an incompatible kernel/module interface change,
please run the systemtap testsuite before & after. If it regresses,
send us a note or a patch. If practical, we'll integrate it (and add
any backward-compatibility hacks if needed) into systemtap.
- FChE
On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
>...
> In the interim (before we come up with a way of moving more
> kernel-coupled systemtap code into kernel.org/git), would y'all
> consider an arrangement? Those of you who care about systemtap, and
> are intending to make an incompatible kernel/module interface change,
> please run the systemtap testsuite before & after. If it regresses,
> send us a note or a patch. If practical, we'll integrate it (and add
> any backward-compatibility hacks if needed) into systemtap.
The number of incompatible kernel/module interface changes per kernel is
most likely some medium three digit number.
What you have in mind is therefore not really feasible.
But we have several levels of kernels that incorporate future stuff,
from -rc over -next to -mm, and you could implement automated runs
of the systemtap testsuite against the latest ones.
> - FChE
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi -
On Wed, Jul 23, 2008 at 07:54:05PM +0300, Adrian Bunk wrote:
> On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
> >...
> > In the interim (before we come up with a way of moving more
> > kernel-coupled systemtap code into kernel.org/git), would y'all
> > consider an arrangement? Those of you who care about systemtap, and
> > are intending to make an incompatible kernel/module interface change,
> > please run the systemtap testsuite before & after. [...]
> The number of incompatible kernel/module interface changes per
> kernel is most likely some medium three digit number. What you have
> in mind is therefore not really feasible.
Do you think so, even if the historical pattern continues that only a
small fraction of those changes actually impact systemtap?
> But we have several levels of kernels that incorporate future stuff,
> from -rc over -next to -mm, and you could implement automated runs
> of the systemtap testsuite against the latest ones.
We do some of that already and should do more.
- FChE
On Wed, Jul 23, 2008 at 01:34:38PM -0400, Frank Ch. Eigler wrote:
> Hi -
>
> On Wed, Jul 23, 2008 at 07:54:05PM +0300, Adrian Bunk wrote:
> > On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
> > >...
> > > In the interim (before we come up with a way of moving more
> > > kernel-coupled systemtap code into kernel.org/git), would y'all
> > > consider an arrangement? Those of you who care about systemtap, and
> > > are intending to make an incompatible kernel/module interface change,
> > > please run the systemtap testsuite before & after. [...]
>
> > The number of incompatible kernel/module interface changes per
> > kernel is most likely some medium three digit number. What you have
> > in mind is therefore not really feasible.
>
> Do you think so, even if the historical pattern continues that only a
> small fraction of those changes actually impact systemtap?
But which are these?
All commits that either remove EXPORT_SYMBOL's or touch include/ are
candidates would have to be checked, and that's a four digit number
of commits per kernel release.
What is not feasible is to check each of thesse commits.
> > But we have several levels of kernels that incorporate future stuff,
> > from -rc over -next to -mm, and you could implement automated runs
> > of the systemtap testsuite against the latest ones.
>
> We do some of that already and should do more.
>
> - FChE
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Frank,
Frank Ch. Eigler wrote:
> Arjan van de Ven <[email protected]> writes:
[...]
>> (and when it's seen it gets a rather luke warm reception, but that's
>> a different story).
>
> I hope the backward compatibility issue, as it stands today, helps
> explain the reasons for the current deal with kprobes.
I understood that the current deal with kprobes is also for integrating
user probe logic and kernel probe logic.
Obviously, it is hard uprobe to provide same symbol_name interface,
because it requires to access(and analyze) userspace symbol
information from kernel.
> In the interim (before we come up with a way of moving more
> kernel-coupled systemtap code into kernel.org/git), would y'all
> consider an arrangement? Those of you who care about systemtap, and
> are intending to make an incompatible kernel/module interface change,
> please run the systemtap testsuite before & after. If it regresses,
> send us a note or a patch. If practical, we'll integrate it (and add
> any backward-compatibility hacks if needed) into systemtap.
Hmm, I think it's very costly way for both of kernel developers and
systemtap developers.
>From the long term of viewpoint, I think it's better (less costly)
to merge systemtap runtime/tapset into upstream kernel and maintain
it. Then, we can stabilize its API by ourselves on upstream.
Since it reduces the catchup/maintenance cost and it enables users
to use stap on upstream kernel, I think it is benefit for both.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: [email protected]