Skip to contentSkip to conversation

adding missing MODULE_* stuffs

KJ Kees Cook 7 participants 11 messages Dec 30, 2005 – Jan 8, 2006 Kernel janitors

lore
Share & tools
lore

Kees Cook

author
#0 lore raw

Would patches towards adding missing MODULE_DESCRIPTION, MODULE_VERSION, and MODULE_AUTHOR stuff be taken? While these aren't covered in the CodingStyle document, I did find reference to their preferred order in Documentation/i2c/porting-clients.txt where Greg KH said the order should be:

MODULE_AUTHOR
MODULE_DESCRIPTION
MODULE_LICENSE /* last line of source */

I'm curious where MODULE_VERSION should go, as well as MODULE_PARAM_DESC.

Notably, AUTHOR, DESCRIPTION, and VERSION seem to be missing from the various examples in Documention/

Signature · 1 line
Kees Cook                                            @outflux.net

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#1 lore raw
Quoted 5 lines · Kees Cook

Would patches towards adding missing MODULE_DESCRIPTION, MODULE_VERSION, and MODULE_AUTHOR stuff be taken? While these aren't covered in the CodingStyle document, I did find reference to their preferred order in Documentation/i2c/porting-clients.txt where Greg KH said the order should be:

I said that? Hm, looks like Jean did, not I :)

Quoted 7 lines

MODULE_AUTHOR
MODULE_DESCRIPTION
MODULE_LICENSE /* last line of source */

I'm curious where MODULE_VERSION should go, as well as MODULE_PARAM_DESC.

Where ever you want them to go. Traditionally the _DESC stuff goes right after the module_param() line, to keep it all together.

Quoted 2 lines

Notably, AUTHOR, DESCRIPTION, and VERSION seem to be missing from the various examples in Documention/

What examples?

thanks,

greg k-h

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

author
#2 lore raw
In reply to Kees Cook
Quoted 1 line · Greg KH

I said that? Hm, looks like Jean did, not I :)

Oh, whoops. I scrolled up just enough to find your name. ;)

Quoted 4 lines
Quoted 2 lines

Notably, AUTHOR, DESCRIPTION, and VERSION seem to be missing from the various examples in Documention/

What examples?

i2c/porting-clients (instructions, rather than code) i2c/writing-clients (same) sound/alsa/DocBook/writing-an-alsa-driver.tmpl firmware_class/firmware_sample_driver.c firmware_class/firmware_sample_firmware_class.c connector/cn_test.c
DocBook/kernel-hacking.tmpl (not really an example, more a description) DocBook/videobook.tmpl
DocBook/procfs_example.c
kprobes.txt

What I was really in the mood for was adding those things to the rest of the code tree too. There are plenty of modules that have authors, versions, and descriptions listed in comments and #define's, but not marked up in MODULE_*() syntax.

Signature · 1 line
Kees Cook                                            @outflux.net

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#3 lore raw
In reply to Kees Cook
Quoted 21 lines · Kees Cook
Quoted 1 line · Greg KH

I said that? Hm, looks like Jean did, not I :)

Oh, whoops. I scrolled up just enough to find your name. ;)

Quoted 4 lines
Quoted 2 lines

Notably, AUTHOR, DESCRIPTION, and VERSION seem to be missing from the various examples in Documention/

What examples?

i2c/porting-clients (instructions, rather than code) i2c/writing-clients (same) sound/alsa/DocBook/writing-an-alsa-driver.tmpl firmware_class/firmware_sample_driver.c firmware_class/firmware_sample_firmware_class.c connector/cn_test.c
DocBook/kernel-hacking.tmpl (not really an example, more a description) DocBook/videobook.tmpl
DocBook/procfs_example.c
kprobes.txt

Quoted 4 lines

What I was really in the mood for was adding those things to the rest of the code tree too. There are plenty of modules that have authors, versions, and descriptions listed in comments and #define's, but not marked up in MODULE_*() syntax.

Sure, start in a directory and work through them all :)

Good luck,

greg k-h

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#4 lore raw

MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

In reply to Kees Cook
Quoted 10 lines · Kees Cook

Would patches towards adding missing MODULE_DESCRIPTION, MODULE_VERSION, and MODULE_AUTHOR stuff be taken? While these aren't covered in the CodingStyle document, I did find reference to their preferred order in Documentation/i2c/porting-clients.txt where Greg KH said the order should be:

MODULE_AUTHOR
MODULE_DESCRIPTION
MODULE_LICENSE /* last line of source */

Quoted 5 lines

I'm curious where MODULE_VERSION should go, as well as MODULE_PARAM_DESC.

Notably, AUTHOR, DESCRIPTION, and VERSION seem to be missing from the various examples in Documention/

I hate MODULE_VERSION. It stops making sense after the following definition:

Version of a module is a version of kernel it was shipped with.

Given: module 8139too version 0.9.27 is buggy in somesuch way.
Question: which one?

There were quite a few nontrivial changes made since transition to git:
-----------------------------------------------------------------------
Christoph Lameter:
Cleanup patch for process freezing

Jeff Garzik:
[netdrvr 8139too] replace hand-crafted kernel thread with workqueue [netdrvr 8139too] use cancel_rearming_delayed_work() to cancel thread [netdrvr 8139too] use rtnl_shlock_nowait() rather than rtnl_lock_interruptible() [netdrvr 8139too] fast poll for thread, if an unlikely race occurs

John W. Linville:
8139too: support ETHTOOL_GPERMADDR
8139too: fix resume for Realtek 8100B/8139D

Olaf Hering:
turn many #if $undefined_string into #ifdef $undefined_string

Pekka Enberg:
8139too: use iomap for pio/mmio
-----------------------------------------------------------------------
None of the above changes touched MODULE_VERSION. It's still 0.9.27.

MODULE_VERSION is almost always outdated. You can't rely on it in bugreports. All you can rely on is kernel version, be it 2.6.15-git1 or 2.6.15-0aec63e67c69545ca757a73a66f5dcf05fa484bf.

#5 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

Hi everyone,

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION
2.- Schedule it for removal in one or two more versions, and automagically use the KERNEL_VERSION as module's version.

Any comments?

Signature · 2 lines
Carlos Manuel Duclos Vergara
http://www.toolchains.com/personal/blog
#6 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

Quoted 4 lines · Carlos Manuel Duclos Vergara

Hi everyone,

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION

No.

Quoted 2 lines

2.- Schedule it for removal in one or two more versions, and automagically use the KERNEL_VERSION as module's version.

No, just let the authors of the different drivers that want to use MODULE_VERSION use it (for some people it does matter, and they keep it up to date.) Everyone else, just don't add it if you don't care about it.

Quoted 1 line

Any comments?

In short, leave it alone :)

thanks,

greg k-h

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#7 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

Quoted 8 lines · Greg KH
Quoted 4 lines · Carlos Manuel Duclos Vergara

Hi everyone,

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION

No.

Quoted 7 lines
Quoted 2 lines

2.- Schedule it for removal in one or two more versions, and automagically use the KERNEL_VERSION as module's version.

No, just let the authors of the different drivers that want to use MODULE_VERSION use it (for some people it does matter, and they keep it up to date.) Everyone else, just don't add it if you don't care about it.

DKMS (http://linux.dell.com/dkms/) uses it to tell if one version is newer than another. For the couple dozen modules Dell regularly cares about, the module authors have been doing a good job of keeping MODULE_VERSION correct, for exactly this reason.

Quoted 1 line

In short, leave it alone :)

Please!

Signature · 4 lines
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#8 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

Quoted 4 lines · Greg KH
Quoted 3 lines · Carlos Manuel Duclos Vergara

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION

vermagic already has KERNEL_VERSION, if that's what someone really cares about.

Signature · 4 lines
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#9 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

In reply to Carlos Manuel Duclos Vergara
Quoted 6 lines · Carlos Manuel Duclos Vergara

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION
2.- Schedule it for removal in one or two more versions, and automagically use the KERNEL_VERSION as module's version.

Any comments?

Do neither. Just because some people don't use it properly is no reason to remove it.

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors

#10 lore raw

Re: MODULE_VERSION useless? (was Re: [KJ] adding missing MODULE_* stuffs)

In reply to Carlos Manuel Duclos Vergara
Quoted 8 lines · Carlos Manuel Duclos Vergara

Hi everyone,

I have two ideas about what to do with MODULE_VERSION:
1.- Defining MODULE_VERSION = KERNEL_VERSION
2.- Schedule it for removal in one or two more versions, and automagically use the KERNEL_VERSION as module's version.

Any comments?

I think there is another option:

3. Always print KERNEL_VERSION in addition to MODULE_VERSION.

Since for some modules MODULE_VERSION is considered useful and KERNEL_VERSION always is useful, this should give the best of both, right?

BR Håkon Løvdal

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors