linux-kernel - Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

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] [day] [month] [year] [list]

Date:	Wed, 23 Jul 2008 18:12:37 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	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 Frank,

Frank Ch. Eigler wrote:
> Arjan van de Ven <arjan@...radead.org> 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: 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/