All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] Rename credit2 names to csched2_*
Date: Fri, 1 Mar 2013 10:38:32 +0000	[thread overview]
Message-ID: <51308528.5060201@citrix.com> (raw)
In-Reply-To: <51306B3E.6030805@ts.fujitsu.com>

On 01/03/13 08:47, Juergen Gross wrote:
> On 01.03.2013 09:20, Jan Beulich wrote:
>>>>> On 01.03.13 at 07:06, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>>> On 27.02.2013 13:43, Jan Beulich wrote:
>>>>>>> On 27.02.13 at 13:19, Juergen Gross<juergen.gross@ts.fujitsu.com>   wrote:
>>>>> Functions, variables, structures and macros in the credit2 scheduler had
>>>>> partially the same names as in the credit scheduler. This makes it hard to
>>>>> find the correct functions in backtraces or cscope.
>>>>>
>>>>> Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*
>>>> I don't think this is a suitable approach - if anything, we should aim
>>>> at having printed static symbols (in backtraces etc) prefixed with
>>>> their source file name. I would even question quite a few of the
>>>> csched_ prefixes in credit1...
>>> Just one other thought: unique names would help for analyzing crash dumps,
>>> too.
>> Only if the crash dump analyzing tool is dumb enough to also
>> not properly qualify non-global names. ELF has all that is needed
>> here, just the code consuming ELF symbol tables in the whole
>> Linux world seems to be ignoring this capability.
> I completely agree with you.
>
> OTOH this does not help really very much for analyzing dumps, using cscope or
> interpreting backtraces of the hypervisor. Unless the tools are changed to
> include the file names (including paths, please!).
>
> Changing the hypervisor accordingly is in our hands.
>
> Using cscope (or similar tools) is possible with duplicate names, even if this
> isn't optimal IMO.
>
> Changing the dump analyzing tool(s) might be possible, but requires
> potentially a longish discussion with the maintainer(s)...
>
> Up to the point when all of this is done, changing the names to be unique seems
> to be a sensible way to make life easier.
>
>
> Juergen
>

And for my crashdump analyser, all I have to go on is
/boot/xen-$VERSION.map, which contains no de-duplication of
similarly-named symbols.

FWIW, I agree with the original patch, as I have fallen over exactly
this issue with the credit scheduler before.

~Andrew

  reply	other threads:[~2013-03-01 10:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27 12:19 [PATCH] Rename credit2 names to csched2_* Juergen Gross
2013-02-27 12:43 ` Jan Beulich
2013-03-01  6:06   ` Juergen Gross
2013-03-01  8:20     ` Jan Beulich
2013-03-01  8:47       ` Juergen Gross
2013-03-01 10:38         ` Andrew Cooper [this message]
2013-03-01 11:36 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51308528.5060201@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=juergen.gross@ts.fujitsu.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.