Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935622AbWK1Fkq (ORCPT ); Tue, 28 Nov 2006 00:40:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S935624AbWK1Fkp (ORCPT ); Tue, 28 Nov 2006 00:40:45 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:12522 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S935622AbWK1Fko (ORCPT ); Tue, 28 Nov 2006 00:40:44 -0500 Date: Tue, 28 Nov 2006 05:40:36 +0000 From: Christoph Hellwig To: Mathieu Desnoyers Cc: "Frank Ch. Eigler" , linux-kernel@vger.kernel.org, Christoph Hellwig , Andrew Morton , Ingo Molnar , Greg Kroah-Hartman , Thomas Gleixner , Tom Zanussi , Karim Yaghmour , Paul Mundt , Jes Sorensen , Richard J Moore , "Martin J. Bligh" , Michel Dagenais , Douglas Niehaus , ltt-dev@shafik.org, systemtap@sources.redhat.com Subject: Re: [PATCH 3/16] LTTng 0.6.36 for 2.6.18 : Linux Kernel Markers Message-ID: <20061128054036.GA29273@infradead.org> Mail-Followup-To: Christoph Hellwig , Mathieu Desnoyers , "Frank Ch. Eigler" , linux-kernel@vger.kernel.org, Andrew Morton , Ingo Molnar , Greg Kroah-Hartman , Thomas Gleixner , Tom Zanussi , Karim Yaghmour , Paul Mundt , Jes Sorensen , Richard J Moore , "Martin J. Bligh" , Michel Dagenais , Douglas Niehaus , ltt-dev@shafik.org, systemtap@sources.redhat.com References: <20061124215401.GD25048@Krystal> <20061128023349.GA2964@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061128023349.GA2964@Krystal> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2240 Lines: 48 On Mon, Nov 27, 2006 at 09:33:50PM -0500, Mathieu Desnoyers wrote: > * Frank Ch. Eigler (fche@redhat.com) wrote: > > One question: > > > > > [...] > > > + /* Markers in modules. */ > > > + list_for_each_entry(mod, &modules, list) { > > > + if (mod->license_gplok) > > > + found += marker_set_probe_range(name, format, probe, > > > + mod->markers, mod->markers+mod->num_markers); > > > + } > > > [...] > > > +EXPORT_SYMBOL(marker_set_probe); > > > > Are you sure the license_gplok check is necessary here? We should > > consider encouraging non-gpl module writers to instrument their code, > > to give users a slightly better chance of debugging problems. > > > > Hi Frank, > > I was kind of expecting this question. Well, it turns out that my markers module > modifies the struct module in module.h to add a few fields. Some drivers that I > won't name (ok, ok I will : clearcase) have the funny habit of distributing > their kernel modules as ".ko" files instead of sending a proper ".o" and later > link it against a wrapper. > > The result is, I must say, quite bad : when I want to add a probe, I iterate on > each modules, verifying if there are any markers in the object. Things gets > really messy when the structure is corrupted. > > The simplest way to work around this non-GPL problem is to completely disable > access to the marker infrastructure to non-GPL modules. I am not against > instrumentation of binary-only modules, but I don't think it is kernel > developer's job to support their broken binary blob distribution. > > I thought that we might use the crc checksum as another criterion. As long as > the machines do not crash when adding markers when such modules are loaded. Please don't add hacks like that for non-GPL modules. But neither should we export any tracing functionality for them. They;re not the kind of people we want to help at all, and Frank just shows once again that he should rather stay away from kernel stuff and keep on writing C++. - 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/