summaryrefslogtreecommitdiffstats
path: root/drivers/mfd/Makefile
diff options
context:
space:
mode:
authorPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>2006-04-10 22:54:28 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-04-11 06:18:45 -0700
commit5ac90c9f78953b1a2ac937cc5a2f90c3521a710e (patch)
tree4358f489334f856690ef4a451c433829352daf19 /drivers/mfd/Makefile
parent7ad04b0d0ebed1844522dd83cca0ef838d1ac673 (diff)
downloadop-kernel-dev-5ac90c9f78953b1a2ac937cc5a2f90c3521a710e.zip
op-kernel-dev-5ac90c9f78953b1a2ac937cc5a2f90c3521a710e.tar.gz
[PATCH] module support: record in vermagic ability to unload a module
An UML user reported (against 2.6.13.3/UML) he got kernel Oopses when trying to rmmod (on a kernel with module unloading enabled) a module compiled with module unloading disabled. As crashing is a very correct thing to do in that case, a solution is altering the vermagic string to include this too. Possibly, however, the code should not crash in this case, even if the module didn't support unloading - it should simply abort the module removal. In this case, fixing that bug would be a better solution. I've not investigated though. (akpm: a bit marginal - root screwed up and shot himself in the foot). Cc: Hayim Shaul <hayim@post.tau.ac.il> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/mfd/Makefile')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud