linux-kernel - Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87384v7b7d.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Mon, 23 Mar 2015 21:41:58 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul Bolle <pebolle@...cali.nl>, peter.lachner@...el.com,
	norbert.schulz@...el.com, keven.boell@...el.com,
	yann.fouassier@...el.com, laurent.fert@...el.com,
	linux-api@...r.kernel.org, Pratik Patel <pratikp@...eaurora.org>,
	Chunyan Zhang <zhang.chunyan@...aro.org>,
	Kaixu Xia <kaixu.xia@...aro.org>
Subject: Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices

Mathieu Poirier <mathieu.poirier@...aro.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
--
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/