All of lore.kernel.org
 help / color / mirror / Atom feed
From: ddutile@redhat.com (Don Dutile)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Change 'Call trace' to 'Call Trace' for tool scanners
Date: Fri, 06 Feb 2015 13:43:26 -0500	[thread overview]
Message-ID: <54D50B4E.1050403@redhat.com> (raw)
In-Reply-To: <20150206153459.GE23190@e104818-lin.cambridge.arm.com>

On 02/06/2015 10:34 AM, Catalin Marinas wrote:
> On Thu, Feb 05, 2015 at 05:30:27PM +0000, Donald Dutile wrote:
>> Receiving reports from service folks that arm64 uses
>> 'Call trace' when dumping stack, instead of the more familiar
>> 'Call Trace'; the former is not being seen by tools that
>> scan for the latter text.  Checking various arches,
>> it appears the mainstream server arches (ia64, mips, ppc,
>> s390, sparc, x86) use 'Call Trace'.
>> This kernel tools script scans for the latter text string as well
>>    tools/testing/selftests/rcutorture/bin/parse-console.sh
>> so it doesn't appear to be arch or vendor specific.
>>
>> Expecting there aren't a significant number of arm64 dump
>> scanners matching on 'Call trace' so recommend making this change
>> now to minimize changes to dump scanning tools for arm64 servers.
>
> Can you not fix the scripts to check for "Call trace" as well? There are
> 4 more architectures in the kernel using this string (avr32, c6x, metag,
> sh). I also wouldn't count kernel logs as user ABI.
>
I could, but I first received this report from other tools used within RH
that scan for 'Call Trace'.   I pointed to parse-console.sh to show
that RH tools weren't the only ones that were wired with that expectation.

So, adding 'Call trace' to parse-console.sh won't resolve all the other
(primarily server crash) tools that currently match on 'Call Trace'.

I agree with you that I don't consider kernel logs as user ABI, but
as I said, the majority of the heavy, server arches have it that way,
and the tools used on those servers have leaned on this expectation to date.

I didn't modify the other arch's b/c they aren't heavy server arches.

We could carry a patch in our downstream, but then the tools don't resolve
the same way when we do upstream<->downstream comparisons which typically
occur with knarly crash scenarios, which this string would likely show up in.

Cheers, Don

      reply	other threads:[~2015-02-06 18:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05 17:30 [PATCH] arm64: Change 'Call trace' to 'Call Trace' for tool scanners Donald Dutile
2015-02-05 17:37 ` Russell King - ARM Linux
2015-02-05 18:18   ` Don Dutile
2015-02-05 18:30     ` Russell King - ARM Linux
2015-02-05 18:46       ` Don Dutile
2015-02-06 15:34 ` Catalin Marinas
2015-02-06 18:43   ` Don Dutile [this message]

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=54D50B4E.1050403@redhat.com \
    --to=ddutile@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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.