linux-kernel - Re: [PATCH] tracing: Export key trace event symbols

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150422130052.4996e231@gandalf.local.home>
Date:	Wed, 22 Apr 2015 13:00:52 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ron Rechenmacher <ron@...l.gov>
Cc:	David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	<linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	"Stephane Eranian" <eranian@...gle.com>
Subject: Re: [PATCH] tracing: Export key trace event symbols

On Wed, 22 Apr 2015 11:35:41 -0500
Ron Rechenmacher <ron@...l.gov> wrote:

> With the understanding, as has been mentioned before, that "only the user space ABI is
> what we keep stable" and that before commit de7b2973903c (tracepoint: Use struct pointer
> instead of name hash for reg/unreg tracepoints) it was just "lucky" that I could use
> the register_tracepoint_* routines as somewhat generic "add hook" routines (from
> external modules), is it now reasonable to accept my patch to allow external modules
> to "add hooks" to key events in Linux?  Why or why not?
> 

As has been mentioned before, the EXPORT_SYMBOL*() calls is for in-tree
modules that need them. If there's no in-tree users of the exported
symbol, that can be grounds for removing them.

But that is more of a guideline than a rule. Preferably, we want people
using the in-tree mechanisms, because as I have said before, if
something is useful for you, it is most likely useful for others. Even
if it is your own home grown utility. You've been keeping it around for
30 years and that says something. It means that it is probably useful
for other people as well.

We resist making small changes for out-of-tree modules because we want
that functionality in tree. Now, if for some reason, we agree that the
functionality does not belong in tree, and all maintainers involved are
OK, we can add a hook for you. But that wont happen until we are
convinced that the functionality you want belongs out of tree and the
in tree mechanisms are not good enough for you.

I'll admit it adds more burden on you. But the net goal of Linux kernel
development is not it improve usability for each individual, but to
improve the infrastructure as a whole, such that the community benefits
in the end, and not just for a few individuals. Yes, it takes more
time, thought and effort, but in the long run, it's a net gain for
everyone (including you :-).

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