Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261654AbUFCH37 (ORCPT ); Thu, 3 Jun 2004 03:29:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261718AbUFCH37 (ORCPT ); Thu, 3 Jun 2004 03:29:59 -0400 Received: from mail.fh-wedel.de ([213.39.232.194]:211 "EHLO mail.fh-wedel.de") by vger.kernel.org with ESMTP id S261654AbUFCH3m (ORCPT ); Thu, 3 Jun 2004 03:29:42 -0400 Date: Thu, 3 Jun 2004 09:29:17 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Davide Libenzi Cc: Linus Torvalds , Horst von Brand , Pavel Machek , Andrew Morton , Arjan van de Ven , Ingo Molnar , Andrea Arcangeli , Rik van Riel , Linux Kernel Mailing List Subject: Re: [RFC PATCH] explicitly mark recursion count Message-ID: <20040603072917.GB20977@wohnheim.fh-wedel.de> References: <200406011929.i51JTjGO006174@eeyore.valparaiso.cl> <20040602131623.GA23017@wohnheim.fh-wedel.de> <20040602182019.GC30427@wohnheim.fh-wedel.de> <20040602185832.GA2874@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1892 Lines: 47 On Wed, 2 June 2004 16:20:24 -0700, Davide Libenzi wrote: > > Think at file_operations as very simple example, and try to find out what > is actually called when somewhere the code does f_op->*(). How would you > build the graph down there. You'd have to record all the functions that > have been assigned to such method throughout the code, and nest *all* > their graph in place. And this will eventually trigger false positives. Bad example, I can deal with that just fine. :) Any code calling f_op->read must not break for any f_op->read. So it is perfectly sane to assume that all get called. I build the graph by turning f_op->read into a pseudo-function that calls all functions ever assigned to f_op->read. > Similar thing with functions that accepts callbacks, either directly or > inside structures. Those I only handle, if the callbacks are inside structures, true. Will fix it when I find the time for it. > And this doesn't even start to take aliasing into > account. What exactly do you call aliasing? Do you have an example? > Hunting stack hungry functions is very good, and having a tool > that is maybe 60% precise in detecting loops is fine too. But requiring > metadata to be maintained to support such tool is IMO wrong. Since Linus feels that said metadata is still useful without any tools, I'll just ignore this objection. ;) Still, some of the complaints were valid, thanks a bunch! My todo list has grown again. J?rn -- Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -- Doug MacIlroy - 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/