mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Bolle <pebolle@tiscali.nl>,
	peter.lachner@intel.com, norbert.schulz@intel.com,
	keven.boell@intel.com, yann.fouassier@intel.com,
	laurent.fert@intel.com, linux-api@vger.kernel.org,
	Pratik Patel <pratikp@codeaurora.org>,
	Chunyan Zhang <zhang.chunyan@linaro.org>,
	Kaixu Xia <kaixu.xia@linaro.org>
Subject: Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices
Date: Mon, 23 Mar 2015 21:41:58 +0200	[thread overview]
Message-ID: <87384v7b7d.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <CANLsYkycrE-VyyLWLYtBFNijhLP8UejVjDEXYv4FBP88eyZrRQ@mail.gmail.com>

Mathieu Poirier <mathieu.poirier@linaro.org> writes:

>> +source "drivers/hwtracing/stm/Kconfig"
>> +
>>  endmenu
>
> When the coresight framework and drivers were submitted for review
> people asked that I move the Kconfig options to
> "arch/arm[64]/kernel.debug", resulting in coresight configurable
> options showing up under the "Kernel Hacking" department.  To me the
> request was not deprived of logic since if one is dealing with HW
> tracing, some serious kernel hacking is likely happening.

To me this is very much a non-sequitur conclusion: if one's likely to
use CONFIG_x for kernel debugging doesn't necessarily mean CONFIG_x is a
strictly kernel debugging feature. One might move serial drivers under
"Kernel Hacking" by the same token. I also suspect that sweeping things
under "Kernel Hacking" is kind of a license to go easy on code review.

> Now that the Intel drivers are coming in, that we have a generic STM,
> and "drivers/hwtracing" has already been created, we should take a
> minute to ponder if tracers for various architecture should go under
> "arch/XYX/kernel.debug" or if we should introduce a new "hwtracing"
> submenu in the drivers list.

I'm in favor of the latter. If some bits in this submenu are strictly
specific to kernel hacking an appropriate dependency can be used.

> Because of the STM sources (which are bound to grow in numbers) I
> _think_ it would be easier to have a new submenu in the drivers list
> but I'm not strongly opinionated on the topic.  Please take a minute
> to think about it and get back to me with your opinion.  I'd also be
> interested to know what other community members think - it's
> definitely not the first time this kind of dilemma happens...

I don't see why any of these should be hidden under Kconfig.debug, they
are mostly device drivers. They shouldn't add any runtime footprint
unless they are actually used and it's up to the user how to use them
(provided we handle capabilities/permissions correctly, which we should
do regardless).

So yes, my opinion -- let's have a submenu in hwtracing.

Regards,
--
Alex

  reply	other threads:[~2015-03-23 19:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 20:32 [PATCH v2 00/11] Introduce Intel Trace Hub support Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices Alexander Shishkin
2015-03-23  1:50   ` Mathieu Poirier
2015-03-23 19:41     ` Alexander Shishkin [this message]
2015-03-26 22:23   ` Greg Kroah-Hartman
2015-03-26 22:35   ` Greg Kroah-Hartman
2015-04-24 22:07   ` Mathieu Poirier
2015-03-22 20:32 ` [PATCH v2 02/11] MAINTAINERS: add an entry for System Trace Module device class Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 03/11] stm class: dummy_stm: Add dummy driver for testing stm class Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 04/11] stm class: stm_console: Add kernel-console-over-stm driver Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 05/11] intel_th: Add driver infrastructure for Intel Trace Hub devices Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 06/11] intel_th: Add pci glue layer for Intel Trace Hub Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 07/11] intel_th: Add Global Trace Hub driver Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 08/11] intel_th: Add Software " Alexander Shishkin
2015-03-22 20:32 ` [PATCH v2 09/11] intel_th: Add Memory Storage Unit driver Alexander Shishkin
2015-03-22 20:33 ` [PATCH v2 10/11] intel_th: Add PTI output driver Alexander Shishkin
2015-03-22 20:33 ` [PATCH v2 11/11] MAINTAINERS: add an entry for Intel(R) Trace Hub Alexander Shishkin

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=87384v7b7d.fsf@ashishki-desk.ger.corp.intel.com \
    --to=alexander.shishkin@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kaixu.xia@linaro.org \
    --cc=keven.boell@intel.com \
    --cc=laurent.fert@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=norbert.schulz@intel.com \
    --cc=pebolle@tiscali.nl \
    --cc=peter.lachner@intel.com \
    --cc=pratikp@codeaurora.org \
    --cc=yann.fouassier@intel.com \
    --cc=zhang.chunyan@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®