linux-kernel - Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

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

Message-ID: <84144f020807180738m768a3ebana5ebc10999f22f50@mail.gmail.com>
Date:	Fri, 18 Jul 2008 17:38:04 +0300
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Eduard - Gabriel Munteanu" <eduard.munteanu@...ux360.ro>
Cc:	cl@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	"Randy Dunlap" <rdunlap@...otime.net>,
	"Matt Mackall" <mpm@...enic.com>
Subject: Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

Hi Eduard-Gabriel,

On Fri, Jul 18, 2008 at 11:48:03AM +0300, Pekka J Enberg wrote:
>> It's an ABI so you want to make it backwards compatible and extensible.
>> Yes, it's just for debugging, so the rules are bit more relaxed here but
>> that's not an excuse for not designing the ABI properly.

On Fri, Jul 18, 2008 at 1:13 PM, Eduard - Gabriel Munteanu
<eduard.munteanu@...ux360.ro> wrote:
> I do expect to keep things source-compatible, but even
> binary-compatible? Developers debug and write patches on the latest kernel,
> not on a 6-month-old kernel. Isn't it reasonable that they would
> recompile kmemtrace along with the kernel?

Yes, I do think it's unreasonable. I, for one, am hoping distributions
will pick up the kmemtrace userspace at some point after which I don't
need to ever compile it myself.

On Fri, Jul 18, 2008 at 1:13 PM, Eduard - Gabriel Munteanu
<eduard.munteanu@...ux360.ro> wrote:
> I would deem one ABI or another stable, but then we have to worry about
> not breaking it, which leads to either bloating the kernel, or keeping
> improvements away from kmemtrace. Should we do it just because this is an ABI?

Like I've said before, it's debugging/tracing infrastructure so the
rules are bit more relaxed. That said, what we should do is (1) make
the ABI as future-proof as we can, (2) explicitly mark it as unstable
by documenting it in Documentation/ABI/testing and (3) at some point
in time move it in Documentation/ABI/stable and hopefully never break
it again. But sure, we probably don't need to keep any "bloat" around
like we do with the syscall interface, for example.

And hopefully, the ABI is good enough to allow adding *new* tracing
events while retaining the old ones nicely in a backwards compatible
way.

On Fri, Jul 18, 2008 at 11:48:03AM +0300, Pekka J Enberg wrote:
>> I really wish we would follow the example set by blktrace here. It uses a
>> fixed-length header that knows the length of the rest of the packet.

On Fri, Jul 18, 2008 at 1:13 PM, Eduard - Gabriel Munteanu
<eduard.munteanu@...ux360.ro> wrote:
> I'd rather export the header length through a separate debugfs entry,
> rather than add this to every packet. I don't think we need variable
> length packets, unless we intend to export the whole stack trace, for
> example.

Sure, makes sense.

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