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

quoted text
> On Fri, Jul 18, 2008 at 1:13 PM, Eduard - Gabriel Munteanu
> <eduard.munteanu@linux360.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.

quoted text
> 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@linux360.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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/