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]
Date:	Wed, 8 Jul 2015 08:15:01 -0600
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Chunyan Zhang <zhang.chunyan@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 1/4] STM trace event: Adding generic buffer
 interface driver

On 8 July 2015 at 04:23, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan@...aro.org> writes:
>
>> From: Mathieu Poirier <mathieu.poirier@...aro.org>
>>
>> This patch adds a driver that models itself as an stm_source and
>> who's sole purpose is to export an interface to the rest of the
>> kernel.  Once the stm and stm_source have been linked via sysfs,
>> everything that is passed to the interface will endup in the STM
>> trace engine.
>>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier@...aro.org>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@...aro.org>
>> ---
>>  drivers/stm/Kconfig           | 11 +++++++++++
>>  drivers/stm/Makefile          |  2 ++
>>  drivers/stm/stm_trace_event.c | 46 +++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 59 insertions(+)
>>  create mode 100644 drivers/stm/stm_trace_event.c
>>
>> diff --git a/drivers/stm/Kconfig b/drivers/stm/Kconfig
>> index 6f2db70..8ead418 100644
>> --- a/drivers/stm/Kconfig
>> +++ b/drivers/stm/Kconfig
>> @@ -25,3 +25,14 @@ config STM_SOURCE_CONSOLE
>>
>>         If you want to send kernel console messages over STM devices,
>>         say Y.
>> +
>> +config STM_TRACE_EVENT
>> +     tristate "Redirect/copy the output from kernel trace event to STM engine"
>> +     depends on STM
>> +     help
>> +       This option can be used to redirect or copy the output from kernel trace
>> +       event to STM engine. Enabling this option will introduce a slight
>> +       timing effect.
>> +
>> +       If you want to send kernel trace event messages over STM devices,
>> +       say Y.
>> diff --git a/drivers/stm/Makefile b/drivers/stm/Makefile
>> index 74baf59..55b152c 100644
>> --- a/drivers/stm/Makefile
>> +++ b/drivers/stm/Makefile
>> @@ -5,3 +5,5 @@ stm_core-y            := core.o policy.o
>>  obj-$(CONFIG_STM_DUMMY)      += dummy_stm.o
>>
>>  obj-$(CONFIG_STM_SOURCE_CONSOLE)     += console.o
>> +
>> +obj-$(CONFIG_STM_TRACE_EVENT)        += stm_trace_event.o
>> diff --git a/drivers/stm/stm_trace_event.c b/drivers/stm/stm_trace_event.c
>> new file mode 100644
>> index 0000000..bc77dae
>> --- /dev/null
>> +++ b/drivers/stm/stm_trace_event.c
>> @@ -0,0 +1,46 @@
>> +/*
>> + * Simple kernel driver to link kernel trace event and an STM device
>> + * Copyright (c) 2015, Linaro Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/console.h>
>> +#include <linux/stm.h>
>> +
>> +static struct stm_source_data stm_trace_event_data = {
>> +     .name           = "stm_trace_event",
>> +     .nr_chans       = 1,
>
> One question is: do we want to cram ftrace data from all cpus into one
> channel or use a channel per cpu?

That's the perennial question.  Even one channel per cpu may not be
sufficient... Some configuration may want to use one channel per
application.  We should favour the solution that offers the most
flexibility - the above was for the RFC only.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ