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
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
trying to call 'insmod -q', which wasn't supported. Secondly, when modprobe
was fed blank lines from modules.dep, we ended up calling xstrndup(ptr, -1),
which with suitably bad results. David provided a patch to catch the blank
lines, and I have added insmod -q support. So modprobe should work again.
-Erik
