Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755736AbYGROiS (ORCPT ); Fri, 18 Jul 2008 10:38:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752324AbYGROiI (ORCPT ); Fri, 18 Jul 2008 10:38:08 -0400 Received: from py-out-1112.google.com ([64.233.166.182]:15988 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800AbYGROiF (ORCPT ); Fri, 18 Jul 2008 10:38:05 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qXCPkCc3yNsCA5fm6e9a4ypSp6HFH4GZlp7ftauXXTubUtshWMgAUDi+eE38MYq7QO NSTEjhTuaUsAARefmr4s8726vjep29TFWqG1uqSrEL+w3MR8ITS3ffdGg5YO/KbKg9M4 kcSgcbaiLbWICjIIaDLqUUaX+2Z9lGAkRYiVc= Message-ID: <84144f020807180738m768a3ebana5ebc10999f22f50@mail.gmail.com> Date: Fri, 18 Jul 2008 17:38:04 +0300 From: "Pekka Enberg" To: "Eduard - Gabriel Munteanu" Subject: Re: [RFC PATCH 1/4] kmemtrace: Core implementation. Cc: cl@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Randy Dunlap" , "Matt Mackall" In-Reply-To: <20080718101326.GB5193@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4472a3f883b0d9026bb2d8c490233b3eadf9b55e.1216255035.git.eduard.munteanu@linux360.ro> <84144f020807170101x25c9be11qd6e1996460bb24fc@mail.gmail.com> <20080717183206.GC5360@localhost> <20080718101326.GB5193@localhost> X-Google-Sender-Auth: 05b53874ece357b7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2598 Lines: 55 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 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 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/