aboutsummaryrefslogtreecommitdiff
path: root/libbb
diff options
context:
space:
mode:
authorandersen <andersen@69ca8d6d-28ef-0310-b511-8ec308f3f277>2004-04-06 11:56:26 +0000
committerandersen <andersen@69ca8d6d-28ef-0310-b511-8ec308f3f277>2004-04-06 11:56:26 +0000
commit056fbedcd15951f349143fa2d87c105c2e6d4793 (patch)
treeb76a80412fce98e865f0e7e756ef8fc6ed8c8151 /libbb
parentce9fe319e1495cc75d47c6c569496a00afe4a8ee (diff)
downloadbusybox-w32-056fbedcd15951f349143fa2d87c105c2e6d4793.tar.gz
busybox-w32-056fbedcd15951f349143fa2d87c105c2e6d4793.tar.bz2
busybox-w32-056fbedcd15951f349143fa2d87c105c2e6d4793.zip
Christian Grigis, christian.grigis at smartdata dot ch writes:
Hello everyone, Busybox's insmod fails to locate a module when that module is the only one existing in the /lib/modules directory (with a unique name). Example: # find /lib/modules/ -type f /lib/modules/kernel/drivers/char/bios.o # insmod bios insmod: bios.o: no module by that name found # touch /lib/modules/dummy # find /lib/modules/ -type f /lib/modules/kernel/drivers/char/bios.o /lib/modules/dummy # insmod bios Using /lib/modules/kernel/drivers/char/bios.o As long as there is another file in the /lib/modules directory, insmod finds it OK. I tracked the problem down to 'check_module_name_match()' in insmod.c: It returns TRUE when a match is found, and FALSE otherwise. In the case where there is only one module in the /lib/modules directory (or more that one module, but all with the same name), 'recursive_action()' will return TRUE and we end up on line 4196 in 'insmod.c' which returns an error. [The reason it works with more than one module with different names is that in this case there will always be one not matching, 'recursive_action()' will return FALSE and we end up in line 4189.] Now, from the implementation of 'recursive_action()' and from other usages of it (tar.c, etc.), it seems to me that FALSE should be returned to indicate that we want to stop the recursion, so TRUE and FALSE should be inverted in 'check_module_name_match()'. At the same time, 'recursive_action()' continues to recurse even after the recursive call has returned FALSE; again in my understanding and other usages of it, we can safely stop recursing at this point. Here is my patch against 1.00-pre8: git-svn-id: svn://busybox.net/trunk/busybox@8697 69ca8d6d-28ef-0310-b511-8ec308f3f277
Diffstat (limited to 'libbb')
-rw-r--r--libbb/recursive_action.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/libbb/recursive_action.c b/libbb/recursive_action.c
index d27629829..72371963f 100644
--- a/libbb/recursive_action.c
+++ b/libbb/recursive_action.c
@@ -100,7 +100,7 @@ int recursive_action(const char *fileName,
100 return FALSE; 100 return FALSE;
101 } 101 }
102 status = TRUE; 102 status = TRUE;
103 while ((next = readdir(dir)) != NULL) { 103 while (status && (next = readdir(dir)) != NULL) {
104 char *nextFile; 104 char *nextFile;
105 105
106 nextFile = concat_subpath_file(fileName, next->d_name); 106 nextFile = concat_subpath_file(fileName, next->d_name);