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: <20080718194059.GA5238@localhost>
Date:	Fri, 18 Jul 2008 22:40:59 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Pekka Enberg <penberg@...helsinki.fi>
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.

On Fri, Jul 18, 2008 at 05:38:04PM +0300, Pekka Enberg wrote:
> Hi Eduard-Gabriel,
> > 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.

Ok, I agree it's nice to have it in distros. I wasn't planning for this,
but it's good to know others' expectations.

Then I'll also add a turn-off mechanism, so maybe it makes it into distro
kernels too (either debug or not). And we don't need to include kernel
headers from userspace anymore and I'll just provide a copy.

BTW, I also expect the kmemtrace-user git repo to become stable soon
(i.e. no more revision history rewrites).

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

Sounds like a good plan. I'll also update the docs (Documentation/ABI/ and
Documentation/vm/kmemtrace.txt) to reflect this.

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