Date: Wed, 14 Jul 2010 13:23:32 -0300
From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@elte.hu>,
        Randy Dunlap <rdunlap@xenotime.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Christoph Hellwig <hch@infradead.org>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Naren A Devaiah <naren.devaiah@in.ibm.com>,
        Jim Keniston <jkenisto@linux.vnet.ibm.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        "Frank Ch. Eigler" <fche@redhat.com>,
        Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 10/13]  perf: Re-Add make_absolute_path
Message-ID: <20100714162332.GA4000@ghostprotocols.net>
References: <20100712103214.27491.15142.sendpatchset@localhost6.localdomain6>
 <20100712103412.27491.18737.sendpatchset@localhost6.localdomain6>
 <20100712140023.GC25238@ghostprotocols.net>
 <1278945036.1537.189.camel@gandalf.stny.rr.com>
 <20100712161239.GF25238@ghostprotocols.net>
 <1279075767.4190.1.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1279075767.4190.1.camel@localhost>
User-Agent: Mutt/1.5.20 (2009-08-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1527
Lines: 32

Em Tue, Jul 13, 2010 at 10:49:27PM -0400, Steven Rostedt escreveu:
> On Mon, 2010-07-12 at 13:12 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jul 12, 2010 at 10:30:36AM -0400, Steven Rostedt escreveu:

> > Well, I prefer to follow the kernel way of doing things, i.e. to
> > propagate as much as possible up the callchain the error return value,
> > so that the apps can handle it in any way they prefer, i.e. die() calls
> > in tools/perf/builtin-foo.c are okayish, but not on tools/perf/util/.

> Ah, yes, die is a bit strong. And I have been starting to avoid them
> too. Although, when malloc fails, it's almost certain that the app will
> die soon anyway ;-)

The interesting thing is that years ago, when modules were being
introduced in the kernel and panic() calls for things like out of memory
conditions were being removed, some people made the same comments, 'if
that happens, you're doomed anyway!' :-)

I can see things like trying to load a huge perf.data file in the TUI
interface failing and the user just being warned about it and going on
with life loading some other file, etc.

Certainly it is interesting to try to apply as much as possible of the
mindset (and fear of criticism) present when coding for the kernel when
one codes for userland.

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