Message-ID: <20080224131001.GA7150@mit.edu>
Date:	Sun, 24 Feb 2008 08:10:02 -0500
From:	Theodore Tso <tytso@....EDU>
To:	John Levon <levon@...ementarian.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, sandmann@...hat.com, tglx@...x.de,
	hpa@...or.com
Subject: Re: [PATCH] x86: add the debugfs interface for the sysprof tool

On Sat, Feb 23, 2008 at 01:53:35PM +0000, John Levon wrote:
> On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:
> 
> > It's 200 lines of pretty well isolated code for something that is 
> > already much more usable to me than 10 years of oprofile. Really, i'd 
> > much rather take 200 lines of poor kernel code written by a userspace 
> > developer for stuff that _already works better_, than to have ~2000 
> > lines of oprofile code and an unusable (to me) user-space tool written 
> > by kernel developers.

I think it's fair to say that oth oprofile and sysprof can use some
improvements.  There are a couple of questions that immediately come
to mind, including the most obvious one, *if* as you John clams, the
oprofile kernel had all of the functionality for the GUI, why wasn't
it used --- could it *perhaps* because the kernel interface for
oprofile wasn't documented well?  Heck, even if sysprof is 200 lines
of code versus 2000 lines of kernel code, most people don't write
extra code unless it's because the 2000 lines of pre-existing code
isn't well documented enough.

> Firstly, the distributions should have set this up automatically. That
> they don't is a distributor bug. The sheer madness of Linux not leaving
> a vmlinux file in a stable known location is hardly something oprofile
> can be blamed for.

Wrong Answer.  People who write userspace helpers *have* to do the
work of the distro's.  It's a bad, bad, bad, Bad, BAD idea to leave it
up to the distributions.  It means that some distributions won't get
it right; other distributions will do it in different ways, making it
harder for users to switch between distro's and making it harder for
people to write distribution-neutral HOWTO's.

There are plenty of things that can be done, including using search
paths to try to find vmlinuz; or maybe even proposing a new standard
such as say for example /lib/modules/`uname -r`/vmlinux being a
synlink to the location of vmlinux.  We already have
/lib/modules/`uname -r`/build and /lib/modules/`uname -r`/source, for
example.

The abdication of responsibility and the lack of trying to solve the
usability issues is one of the things that really worries me about
*all* of Linux's RAS tools.  We can and should do better!  And it's
really embarassing that the RAS maintainers seem (I assume you are one
of the oprofile maintainers), seem to be blaming this on the victims,
the people who are complaining about using *your* tool.  Yes, it's a
shame that Ingo didn't try to fix your tool; open source, and scratch
your own itch and all of that.  To be sure.  But at the *same* *time*
don't you have enough pride to take a look at a tools which so
obviously has massive lacks in the usability department, and tried to
fix it years ago?  There's more than enough blame to go around twenty
times over, I would think.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists