It is impossible to formulate sane ABI based on
size of ulong because it can be 32-bit or 64-bit.
Basically it means that you cannot portably use
more that 32 option chars in one call anyway...
Make it explicit.
were using "1" as one of the arguments anyway, and as for the rest a multiply
and a push isn't noticeably bigger than pushing two arguments on the stack.
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
the start of the path. (This should be under the same config option as
the standalone shell, but right now that's buried in the shell menu.)
Also add the ability to specify CONFIG_BUSYBOX_EXEC_PATH with /proc/self/exe
as an overrideable default.
and eventual platform specific includes in early.
- remove two supposedly superfluous newlines from ...error_msg() in modprobe
and use shorter boilerplate while at it.
I found that lsmod in busybox does not support linux-2.6.
I fix this issue(it is caused by changes of /proc/modules format).
If you use lsmod in busybox with kernel-2.6, please use this patch.
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
Attached patch prevents modprobe from trying to call 'insmod (null)'
whenever nonexistent module is either passed to modprobe via command
line or mentioned in modules.dep
this replaces cryptic error
sh: Syntax error: word unexpected (expecting ")")
with
modprobe: module some-module not found.
egor.
sparc and ia64 (itanium).
Also, reorganize the insmod architecture support code to be
alphasorted and less messy.
Update the readme to list current insmod arch support.
Hello,
function build_dep in modprobe.c assumes that dependencies of one module
have not more than 255 chars;
that is not sufficient in kernel 2.6.7 (alsa sound modules). - Below is
a diff that solves the problem for me.
With regards, Christian Ostheimer
"There seems to be a slight problem with the "mod_strcmp" function in
modprobe.c, it scans for the first occurence of the module name in the
"mod_path" variable and expects it to be the last path element. ie
/lib/modules/2.4.22-debug/kernel/fs/vfat in my example. The comparison
will always fail if mod_path contains another substring matching the
module name."
Robert McQueen wrote
"Although William Barsse's patch fixed mod_strcmp for 2.4 kernels, there
was a remaining problem which prevented it from working for me. I've
just tracked it down - when you enable kernel 2.6 module support it
hard-wired the extension to .ko instead of checking at runtime like the
other places where 2.4 differs from 2.6. The attached patch fixes this
for me."
fixes two other issues (plus the previous as well) with a 2.4 kernel :
- should be able to modprobe an already loaded module and get 0 return
code :
# modprobe <something> && modprobe <something> && echo "ok" || echo "failed"
....
failed
Well, hope this helps and that I didn't screw up again,
- William
Support for /etc/modprobe.conf (for 2.6 kernels) should likely be added
to bb's modprobe, see attached patch.
modprobe.conf is just a (even simpler) variant of modules.conf
Hi,
There was some problem with busybox modprobe. For details see
http://www.busybox.net/lists/busybox/2004-May/011507.html
I made a patch against busybox-1.00-pre10 to fix that one.
This is a slight variant of Patrick's patch with a slightly
cleaner implementation of mod_strcmp()
-Erik
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
Fix parsing of all tag-value pairs (in modules.conf in particular).
Without this fix, code chokes badly on lines where either value or
both tag+value are missing, like bare
alias
line, or alias w/o the value like
alias some-module
(syntactically incorrect, but no need for coredumps either).
Initialize all fields of struct dep_t.
Without that, e.g. `busybox modprobe -v char-major-10-144' *sometimes*
fails this way (strace):
write(1, "insmod nvram `\213\f\10\n", 21) = 21
Note the garbage after module name which is taken from the m_options field,
which is not initialized in the alias reading/parsing part.
(Shell properly complains to this command, telling it can't find the
closing backtick)
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:
I have found the problem in modprobe, so here is the promised patch
At the current stage I can use it as modprobe while switching between
2.4 and 2.6 seemlesly...(that is good!)
accept more then 1 dependency per modules.dep line. Also white space cleanup...
I think that parsing still breaks sometimes, but is mostly functional now.
Erik, I think we have met online some time ago when I was in Corel/Rebel
Netwinder project....
Anyway, I would like to use BB on 2.6.0 initrd. 1.00-pre4 works OK, if
insmod is actually presented with a full path to the module. Otherwise -
problems (not to mention conflicts when 2.4 modutil is enabled)
Here are some patches for insmod and modprobe which try to walk around
the default ".o" module format for 2.2/2.4 modules (you have probably
noticed it is now .ko in 2.6 ;-)) Trying to steal as little space as
possible if 2.6 not enabled...
The modprobe is still not perfect on 2.6 - seems to be jamming on some
dependencies, but works with some (to be debugged). Anyway after the
patches it at least tries to work....
Will there be a 1.00-pre5 coming any time soon?
Thanks, Woody
Hey guys. I've found a bug in modprobe where it generates bad strings and
makes sytem calls with them. The following patch seems to have fixed the
problem. It is rather inherited elsewhere, as there seems to be incorrect
entries in the list which results in more dependencies than really exist for
a given call to mod_process. But, this patch prevents the bad text from
going to the screen. You will notice there are cases where lcmd goes
unmodified before calling system.
Please consider the following patch.
Thanks.
-Steve
- attempting to modprobe a module that is already loaded yields "Failed
to load module", whereas modutils quietly ignores such a request.
- if a module genuinely can't be loaded due to missing symbols or
similar problems, modprobe doesn't produce any useful diagnostics
because the output from insmod has been redirected to /dev/null.
Here's a patch to address these issue
Patch by Philip Blundell
the output of lsmod (busybox-1.00-pre2) contains IMHO one "\n" too
much when using CONFIG_FEATURE_CHECK_TAINTED_MODULE:
~ # lsmod
Module Size Used by Tainted: P
ds 8364 1
m8xx_pcmcia 5388 1
pcmcia_core 40736 0 [ds m8xx_pcmcia]
and this patch from Steven fixes the problem
Hello all,
This patch adds more "Help" text to the config system. Almost
all applets now have a help entry. Also, I cleaned up the spacing of
the existing text so that things are consistent. This patch is against
this morning's CVS.
Thomas Cameron
CEI Systems, Inc.
I've had some issues with modprobe which I reported a few months ago. This
is still an issue so I decided to sort it out.
The attached diff includes the changes against the unstable cvs tree that
work for me.
Changes are:
mod_process() will report success if the module at the head of the list
loads successfully. It will also report success if any module unloads
successfully.
The net result being that modprobe will succeed in the cases outlined below.
I've also added error reporting to modprobe -r. Previously it would silently
fail (but report success) if the module could not be unloaded.
Andrew
