Prev: NOTICE!
Next: [PATCH] check name_len before down_read xattr_sem and sb_read in ext2_xattr_get
From: Srikar Dronamraju on 12 Jul 2010 13:40
>
> > Actually we dont need to convert malloc(a)libc-2.5.so to a
> > malloc@/lib/libc.so.6. Because we can match the shortname of the dso.
>
> Humm, I see, it is path based, so the first libc-2.5.so that appears in
> the LD_LIBRARY_PATH equivalent used in this code will be user, is that
> right?

No, As you might have got it by reading patch 11. I am trying to
reuse the thread/session elements and walk thro the maps in the
map_groups. So I dont need to bother on LD_LIBRARY_PATH.
>
> I.e. if I'm testing some new libc-2.5.so that provides, say, private
> futexes while the one in my distro still doesn't have this feature, I'll
> have to specify the absolute name or make sure it is before the system's
> libc-2.5.so in the LD_LIBRARY_PATH, right?

We get to the right one, as we walk the list of dsos in the
threadlist. But we have an option of either giving a correct full path
or the shortname for the dso without any path. However right now the
shortname has to be unique i.e I cant use malloc(a)libc instead of
malloc(a)libc-2.5.so. I would think specifying full path will be the most
probable usage case. However if a person refers /proc/<pid>/maps,
specifying shortnames should also be easy.

>
> > Problem will occur when users specifies a full path of the file.
> > Since the file can refer to a symbolic link and the dso will have just
> > the short name or the target file name. Here I am using
> > make_absolute_path to resolve to the target file.
> > Now we can then either check on dso full names or short names.
> > I have chosen to use the short name.
>
> Humm, so what you want is one of:
>
> realpath - return the canonicalized absolute pathname
> canonicalize_file_name - return the canonicalized filename
>
> Can you please check the man pages for both before we decide
> re-introducing make_absolute_path?

right, realpath is right choice, I will use it instead of this patch.


--
Thanks and Regards
Srikar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 13 Jul 2010 23:00
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 ;-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 14 Jul 2010 12:30
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 14 Jul 2010 16:50

* Arnaldo Carvalho de Melo <acme(a)infradead.org> wrote:

> 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.

Yeah, and especially for perf the absolutely most important quality is
reliability. It's not just an app - it's a measurement tool. People rely on it
to reject or apply patches, on a daily basis.

perf must be very reliable and very dependable (and i'm happy that we managed
to achieve that goal so far :), and if it fails it should be apparent that it
failed and that results should not be relied on.

With other tools that are statistical i've sometimes seen a special type of
dangerous attitude of: "hey, it's just a sample, no biggie if it's lost, it's
just statistical anyway, lost in the noise" - but that's really a slippery
slope leading to a sloppy tool we cannot depend on 110%.

Just like physicists or engineers want to be able to trust their measurement
instruments, do we want kernel hackers to be able to trust the results of
perf.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mathieu Desnoyers on 14 Jul 2010 17:00
* Ingo Molnar (mingo(a)elte.hu) wrote:
>
> * Arnaldo Carvalho de Melo <acme(a)infradead.org> wrote:
>
> > 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.
>
> Yeah, and especially for perf the absolutely most important quality is
> reliability. It's not just an app - it's a measurement tool. People rely on it
> to reject or apply patches, on a daily basis.
>
> perf must be very reliable and very dependable (and i'm happy that we managed
> to achieve that goal so far :), and if it fails it should be apparent that it
> failed and that results should not be relied on.
>
> With other tools that are statistical i've sometimes seen a special type of
> dangerous attitude of: "hey, it's just a sample, no biggie if it's lost, it's
> just statistical anyway, lost in the noise" - but that's really a slippery
> slope leading to a sloppy tool we cannot depend on 110%.
>
> Just like physicists or engineers want to be able to trust their measurement
> instruments, do we want kernel hackers to be able to trust the results of
> perf.

I'm glad to see we're on the exact same page here. :)

Having reliable trace analysis tools is crucially important for both kernel
developers and end-users, especially when, as an example, someone try to use the
results to find out which is the "one" odd-case longest/shortest interrupt
handler during a day-long trace while trying to pinpoint a bug.

Thanks,

Mathieu

>
> Thanks,
>
> Ingo

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: NOTICE!
Next: [PATCH] check name_len before down_read xattr_sem and sb_read in ext2_xattr_get