(curious how, when i try to write about something, i find these
obscure, dark corners i'd never noticed before.)
typically, in a loadable module's module_init() routine, you return
either zero (representing success, whereupon the module loads), or a
negative value of the form -E<something>, an error value from the
header file <asm-generic/errno-base.h>:
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* Interrupted system call */
#define EIO 5 /* I/O error */
... etc etc ...
so, for example
return -EIO;
but i'd never noticed what happens when you return a *positive* value:
return 42;
from /var/log/messages:
...
Jun 29 04:42:19 localhost kernel: hi module being loaded.
Jun 29 04:42:19 localhost kernel: User space process is 'insmod'
Jun 29 04:42:19 localhost kernel: User space PID is 30051
Jun 29 04:42:19 localhost kernel: sys_init_module: 'hi'->init
suspiciously returned 42, it should follow 0/-E convention
Jun 29 04:42:19 localhost kernel: sys_init_module: loading module
anyway...
Jun 29 04:42:19 localhost kernel: Pid: 30051, comm: insmod Tainted: G
M 2.6.29.5-191.fc11.x86_64 #1
Jun 29 04:42:19 localhost kernel: Call Trace:
Jun 29 04:42:19 localhost kernel: [<ffffffff8106f33b>]
sys_init_module+0x13e/0x1cd
Jun 29 04:42:19 localhost kernel: [<ffffffff8101133a>]
system_call_fastpath+0x16/0x1b
...
how curious. so returning a positive value still allows the
module to load, it just warns you that it's kind of non-standard,
recommends the "0/-E" convention, and gives you a traceback. i'd
never noticed that before. is there a rationale for that? would that
feature be useful somewhere?
rday
p.s. it makes me wonder if there are any loadable modules anywhere in
the tree whose module_init() routine is inadvertantly returning the
positive value for an error code by accident. that is:
return EINVAL;
as opposed to the correct
return -EINVAL;
i have no idea how i'd quickly scan for that -- it looks a bit tricky.
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
