linux-kernel - Re: [PATCH v0 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]

Date:	Tue, 17 Mar 2015 12:13:47 +0200
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Pratik Patel <pratikp@...eaurora.org>,
	mathieu.poirier@...aro.org, 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
Subject: Re: [PATCH v0 01/11] stm class: Introduce an abstraction for System Trace Module devices

Paul Bolle <pebolle@...cali.nl> writes:

> On Sat, 2015-03-07 at 13:35 +0200, Alexander Shishkin wrote:
>>  Documentation/ABI/testing/configfs-stp-policy    |  44 ++
>
> git am whined about this file when I tried to apply this patch:
>     Applying: stm class: Introduce an abstraction for System Trace Module devices
>     [...]/.git/rebase-apply/patch:77: new blank line at EOF.
>
>>  Documentation/ABI/testing/sysfs-class-stm        |  14 +
>>  Documentation/ABI/testing/sysfs-class-stm_source |  11 +
>>  Documentation/trace/stm.txt                      |  77 +++
>>  drivers/Kconfig                                  |   2 +
>>  drivers/Makefile                                 |   1 +
>>  drivers/stm/Kconfig                              |   8 +
>>  drivers/stm/Makefile                             |   3 +
>>  drivers/stm/core.c                               | 839 +++++++++++++++++++++++
>>  drivers/stm/policy.c                             | 470 +++++++++++++
>>  drivers/stm/stm.h                                |  77 +++
>>  include/linux/stm.h                              |  87 +++
>>  include/uapi/linux/stm.h                         |  47 ++
>
>> --- /dev/null
>> +++ b/drivers/stm/Kconfig
>> @@ -0,0 +1,8 @@
>> +config STM
>> +	tristate "System Trace Module devices"
>> +	help
>> +	  A System Trace Module (STM) is a device exporting data in System
>> +	  Trace Protocol (STP) format as defined by MIPI STP standards.
>> +	  Examples of such devices are Intel Trace Hub and Coresight STM.
>> +
>> +	  Say Y here to enable System Trace Module device support.
>> diff --git a/drivers/stm/Makefile b/drivers/stm/Makefile
>> new file mode 100644
>> index 0000000000..adec701649
>> --- /dev/null
>> +++ b/drivers/stm/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_STM)	+= stm_core.o
>> +
>> +stm_core-y		:= core.o policy.o
>
> I tried to compile this as a module:
>     $ make -C ../.. M=$PWD CONFIG_STM=m stm_core.ko
>     make: Entering directory `[...]'
>       LD [M]  [...]/drivers/stm/stm_core.o
>     [...]/drivers/stm/policy.o: In function `stp_configfs_init':
>     policy.c:(.text+0x5f0): multiple definition of `init_module'
>     [...]/drivers/stm/core.o:core.c:(.init.text+0x0): first defined here
>     make[1]: *** [[...]/drivers/stm/stm_core.o] Error 1
>     make: *** [stm_core.ko] Error 2
>     make: Leaving directory `[...]'
>
> I think that's because
>     postcore_initcall(stm_core_init);
>
> in core.c becomes
>     module_init(stm_core_init);
>
> if this driver is compiled as a module. And that will clash with
>     module_init(stp_configfs_init);
>
> in policy.c. Am I missing something obvious or should STM not be a
> tristate symbol?

My mistake, I think I fancied the policy to be a separate module in the
beginning. But I don't see why STM shouldn't be a tristate after the
above is fixed.

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