I humbly submit for your consideration: (please cc, im not subscribed)
[jimc@groucho linux]$ diff -u module.h module.h.new
--- module.h Wed Feb 27 04:22:33 2002
+++ module.h.new Tue Mar 5 15:39:39 2002
@@ -206,6 +206,10 @@
const char __module_author[] __attribute__((section(".modinfo"))) =
\
"author=" name
+#define MODULE_AUTHORS_VERSION(name) \
+const char __module_authors_version[]
__attribute__((section(".modinfo"))) = \
+"authors_version=" name
+
#define MODULE_DESCRIPTION(desc) \
const char __module_description[] __attribute__((section(".modinfo")))
= \
"description=" desc
intent is to make more info available to modinfo.
hopefully the macro name is good enough to make this obvious,
ie distinguish it from MODVERSIONS etc..
Im slightly puzzled why its not already there, (it makes me think Im
missing something),
but I did the search (this isnt same as AUTHOR printk thread (83) from
last summer),
so what the heck ...
assuming this patch is accepted, should I ? (being an optimist here)?
1. grep sources and patch modules which have a VERSION of some sort, like
arch/i386/kernel/mtrr.c:#define MTRR_VERSION "1.40 (20010327)"
arch/i386/kernel/microcode.c:#define MICROCODE_VERSION "1.09"
ie should i do the janitor work, or leave it to authors/maintainers ?
case-by-case ?
2. or should I try to devise a better macro that slaps together __FILE__
and "_VERSION" to
automatically provide the macro definitions created by the above #defines.
This could be mis-used where filename != module-name, unless the macro,
when cppd in,
can selectively undef itself. ( this option is mostly food for thought,
dunno if its practical )
3. modinfo patches ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:51 EST