Re: [RFC PATCH v3 1/4] STM trace event: Adding generic buffer interface driver
From: Mathieu Poirier
Date: Wed Jul 08 2015 - 10:15:10 EST
On 8 July 2015 at 04:23, Alexander Shishkin
<alexander.shishkin@xxxxxxxxxxxxxxx> wrote:
> Chunyan Zhang <zhang.chunyan@xxxxxxxxxx> writes:
>
>> From: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>
>>
>> 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@xxxxxxxxxx>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@xxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/