Writing modules for 2.5
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · [email protected] (Måns Rullgård) writes:
What magic needs to be done when writing modules for linux 2.5.x? Insmod tells me "Invalid module format" and the kernel log says "No module found in object". I've tried to mimic the
foo.mod.cstuff in the kernel tree, but I can't figure out the right way to do it.
Welcome to the wonderful new world of in kernel module loading, finally with understandable error messages. Now bad error reporting is not limited to netlink anymore.
You need -DKBUILD_BASENAME=name
Also you need module_init/module_exit declarations.
-Andi
Quoted 10 lines · Andi Kleen
Quoted 4 lines
What magic needs to be done when writing modules for linux 2.5.x? Insmod tells me "Invalid module format" and the kernel log says "No module found in object". I've tried to mimic the
foo.mod.cstuff in the kernel tree, but I can't figure out the right way to do it.Welcome to the wonderful new world of in kernel module loading, finally with understandable error messages. Now bad error reporting is not limited to netlink anymore.
You need -DKBUILD_BASENAME=name
Should I also add -DKBUILD_MODNAME=name?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 7 lines · M?ns Rullg?rd
Quoted 5 lines · Andi Kleen
Quoted 4 lines
What magic needs to be done when writing modules for linux 2.5.x? Insmod tells me "Invalid module format" and the kernel log says "No module found in object". I've tried to mimic the
foo.mod.cstuff in the kernel tree, but I can't figure out the right way to do it.
Quoted 7 lines
Quoted 5 lines
Welcome to the wonderful new world of in kernel module loading, finally with understandable error messages. Now bad error reporting is not limited to netlink anymore.
You need -DKBUILD_BASENAME=name
Should I also add -DKBUILD_MODNAME=name?
Yes.
-Andi
Quoted 5 lines · Andi Kleen
Quoted 4 lines
What magic needs to be done when writing modules for linux 2.5.x? Insmod tells me "Invalid module format" and the kernel log says "No module found in object". I've tried to mimic the
foo.mod.cstuff in the kernel tree, but I can't figure out the right way to do it.
Quoted 7 lines
Welcome to the wonderful new world of in kernel module loading, finally with understandable error messages. Now bad error reporting is not limited to netlink anymore.
You need -DKBUILD_BASENAME=name
Also you need module_init/module_exit declarations.
Next question: what is the correct replacement for MOD_INC_USE_COUNT?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 1 line · Måns Rullgård
Next question: what is the correct replacement for
MOD_INC_USE_COUNT?
"SET_MODULE_OWNER(dev);" or simply "dev->owner=THIS_MODULE;" and the counting should then be done automatically AFAIK.
Quoted 3 lines
Signature · 2 lines
Måns Rullgård [email protected]
Regards,
Andreas Henriksson
Quoted 4 lines · Andreas Henriksson
Quoted 1 line
Next question: what is the correct replacement for
MOD_INC_USE_COUNT?"
SET_MODULE_OWNER(dev);" or simply "dev->owner=THIS_MODULE;" and the counting should then be done automatically AFAIK.
OK, but what might dev be and when should this be done? What about MOD_DEC_USE_COUNT?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 5 lines · Andreas Henriksson
Quoted 1 line · Måns Rullgård
Next question: what is the correct replacement for
MOD_INC_USE_COUNT?"
SET_MODULE_OWNER(dev);" or simply "dev->owner=THIS_MODULE;" and the counting should then be done automatically AFAIK.
You don't need that for char drivers.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 1 line · Måns Rullgård
Next question: what is the correct replacement for
MOD_INC_USE_COUNT?
If you know the use count is already one there isnt one, jut use MOD_INC_USE_COUNT and flame Rusty
If you can't prove the use count is already one for your own module you have a problem (and did in 2.4 in truth). The layers try and lock the layer below. So char drivers are locked by core code, block drivers likewise, tty drivers and so on...
Most driver layers now have an owner: field in the file ops or other structure they register
owner: THIS_MODULE,
(THIS_MODULE comes out currently in a non modular buils too)
Quoted 10 lines · Alan Cox
Quoted 1 line
Next question: what is the correct replacement for
MOD_INC_USE_COUNT?If you know the use count is already one there isnt one, jut use
MOD_INC_USE_COUNTand flame RustyIf you can't prove the use count is already one for your own module you have a problem (and did in 2.4 in truth). The layers try and lock the layer below. So char drivers are locked by core code, block drivers likewise, tty drivers and so on...
Quoted 6 lines
Most driver layers now have an owner: field in the file ops or other structure they register
owner:
THIS_MODULE,(
THIS_MODULEcomes out currently in a non modular buils too)
My situation is like this: I am converting a char device driver to work with linux 2.5. In the open and close functions there are MOD_INC/DEC_USECOUNT calls. The question is what they should be replaced with. Will it be handled correctly without them?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 4 lines · Måns Rullgård
My situation is like this: I am converting a char device driver to work with linux 2.5. In the open and close functions there are MOD_INC/DEC_USECOUNT calls. The question is what they should be replaced with. Will it be handled correctly without them?
If it's a character device driver using the struct file_operations, set the owner field as Alan mentioned, and remove the MOD_{INC,DEC}_USE_COUNT macros from the open/close methods. This allows chrdev_open() (in fs/char_dev.c) to increment your module use count automatically.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 11 lines · Russell King
Quoted 4 lines · M?ns Rullg?rd
My situation is like this: I am converting a char device driver to work with linux 2.5. In the open and close functions there are MOD_INC/DEC_USECOUNT calls. The question is what they should be replaced with. Will it be handled correctly without them?
If it's a character device driver using the struct
file_operations, set the owner field as Alan mentioned, and remove the MOD_{INC,DEC}_USE_COUNT macros from the open/close methods. This allowschrdev_open()(infs/char_dev.c) to increment your module use count automatically.
Unless the open/close functions are doing funky things (like the watchdog drivers do).
Dave
Quoted 10 lines · Russell King
Quoted 4 lines
My situation is like this: I am converting a char device driver to work with linux 2.5. In the open and close functions there are MOD_INC/DEC_USECOUNT calls. The question is what they should be replaced with. Will it be handled correctly without them?
If it's a character device driver using the struct
file_operations, set the owner field as Alan mentioned, and remove the MOD_{INC,DEC}_USE_COUNT macros from the open/close methods. This allowschrdev_open()(infs/char_dev.c) to increment your module use count automatically.
Does this work in 2.4 also, or is the owner field used for something else there?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 1 line · Måns Rullgård
Does this work in 2.4 also
Yes.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 4 lines · Måns Rullgård
My situation is like this: I am converting a char device driver to work with linux 2.5. In the open and close functions there are MOD_INC/DEC_USECOUNT calls. The question is what they should be replaced with. Will it be handled correctly without them?
Remove the MOD_INC/DEC counts in the open/close path and add
owner: THIS_MODULE in the file ops, and all is happy.